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ABSTRACT 


There is much to be done to update the Naval Reserve 
automated information systems to 1980's technology. This 
thesis analyzes the Naval Reserve's automated information 
system- the Reserve Training Support System(RTSS). It pres- 
ents the system's background and specifications, its prob- 
lems and the Reserve's own plan to resolve these problems. 
After a discussion on the characteristics of an effective 
automated information system, &TSS is critigued. The key 
issue is the obsolescence of the hardware and software being 
used. To alleviate their information problems, the 
Reserve's must develop a plan to implement new hardware and 
software technology in a coordinated fashion. An alterna- 
tive is presented to the traditional system develcpment 
process: prototyping. Relational database theory is briefly 
discussed. ORACLE, a relational database management systen, 
is used to implement the database prototype that serves as 
an exampie of how current technology can be used to elinmi- 
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I. INTRODUCTION 

TA this thesis we present an approach for solving “a 
portion of the ADP problems of the Naval Reserve. we havea 
two-fold purpose in this effort. 

rarst, we have a strong desire to produc2 a usable 
product. We want to do something functional, while satis- 
fying the academic requirement for a thesis. To that end, 
we called on the experiences of our advisors with Automated 
Information Systems (AIS) in the Naval Reserve; specifi- 
cally, their experié€nce with the Reserve Training Sufport 
System (RTSS). They believed that much remained to be done 
in updating the Reserve Information Systems to 1980's tech- 
nolocy. Second, we both have a strong desire to usea 
fourth generation relational language. One of these commer- 
emailwort “the Shelf "prodiicts, “ORACLE, “is installed on the 
Computer Science Departments VAX 11/780 computer at the 
Naval Postgraduate School and is available for our research. 
The factor bringing the two together became evident early in 
our research when we discovered that ORACLE could run on the 
equipment being installed for kfSS, given an operating 
system conversion or change. 

In gathering the appropriate background informaticn for 
our topic we were immediately presented with larger issues. 
The concepts of strategic policy and organizational pnilos- 
ophy in Information Systems management must first be 
addressed and resolved by an organization before a new 
computer system will be effective. To have discussed just 
the one system in question without discussing the issue of 
the present and future status of Information Management for 
the Reserves would have been mvyopic; too many questions 


would have been left unanswered. 


Moreover, &TSS must not be seen merely in the short 
sighted light of separate Reserve organizational issues. 
Certainly the Reserves have unigue mission Lrequirements; 
they are presently developing their own unique architectures 
to meet advancing Information System Management issues head 
on. But Reserve issues are Navy issues, Navy problems are 
Reserve problems, and so on. Indeed, we believe our 
research will show that many of the problems the Reserves 
face today have arisen from the lack of a clear delineation 
of where the Reserves and the Navy's AIS needs differ. 

Thus our treatise progresses iron background and 
specifics on RTSS, to a wider scope of AIS ovroblems and 
issues facing the Reserves, and back to more RTSS specifics. 
We present kindred problems and issues for the parent Navy 
using the vehicle of a CNO ordered blue ribbon panel of 
experts recruited by the National Science Foundation. We 
then address present and academic design/redesign stratejies 
for the Naval Reserve, and introduce our choice for 
attacking this problem of considerable scope. Finally, ve 
invested a large amount of time learning ORACLE, and offer 
this prototyp2? as an attempt to starting afresh. Our proto- 
type is only an example; it is illustrative of what can be 
accomplished with a fourth generation relational system. fe 
think our problem solving approach fits soundly with the 


recommendations of independent studies of those larger 


issues. 

Chapter One is an overview of the thesis, with brief 
Summaries of the chapters and the thoughts behind our 
overall approach. It knits the far-reaching research 


efforts towards a meaningful conclusion. 

Chapter Two is a background investigation of RTSS(Air), 
with a brief look at a concurrent and partially redundant 
System in the RTSS family, RTSS(Training Management). we 


look at the intended purposes and surrounding policies of 
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the system as it has grown. We present the hardware and 


software environments for the systen, and then address the 
progress and problems in the Reserves't implementation 
efforts. 


Chapter Three is the transition in which we focus on the 
concept of informaticn as a resource; the ways the Navy, the 
Reserves, and specificaliy RTSS, have dealt with this issue 
are presented. We = nOLe some excating and ambitious flans 
Poe the future aS fut forth in the latest information 
systems strategic plans for the Navy and the Reserves. we 
then transition through brief discussions of implementing 
current technology and systems development methodologies to 
the prototyping concert. 

Chapter Four is the Prototype. iin Clt Ort to bring 
the reader who is unfamiliar with relational databases 
onboard, we have inciuded a brief discussion of some germane 
terms and concepts at the start. We then present a discus- 
Sion of ORACLE and how we used its features to implement our 
prototype design. We have taken some rather large manuals 
for uSing ORACLE and condensed them into a simplified 
approach to what the system is capable of doing, and what we 
did with it. 

Chapter Five is our final conclusions and recommenda- 
Ons . Included are recommendations for the Naval Air 
Reserve and the path it should take. Finally, we discuss 
the next steps to be taken in the development of the 
PEOCOtYpe. 


vA 


AS aS TORY 


The Reserve Training Support System (R@SS) is essen- 
tially the same as the active duty system known as the 
Aviation Training Support System (ATSS). The ATS5 congese 
was devised early in 1971 by the Ling Temco Vought (LTV) 
AeroSpace Corporation to aid training coordination and 
scheduling at one of the Navy's A-7 aircraft Fleet Readiness 
Squadrons (FES), Attack Squadron One Hundred Twenty-Two 
(VA-122) at the Naval Air Station at Lemoore, California. 
The initial version was tested at VA-122's Fleet Readiness 
Aviation Maintenance Personnel (FRAMP) Department. The 
primary job of a FRAMP Department at an FRS was to ensure 
that enlisted aviation maintenance personnel were provided 
to fleet operational squadrons adequately trained to perform 
their jobs. The original goal of the system was to provide 
a training support system oriented toward enlisted aircraft 
Maintenance training, and was developed out of a need for 
relief in assigning courses and classes and tracking 
students. ATSS also alleviated the manual generaticn of 
reports, forms, and other paperwork associated with a major 
training syllabus. It was initially a small software 
package consisting of 20 programs designed to manage _ 101 
data items concerning the receipt, transfer, and cour se/ 
class assignment of enrolled and future FRAMP students. 

The early success of ATSS led to adaptations by other 
communities. The system has had a number of titles associ- 
ated with it since Vaal = OL Ga naveky known as 
Computer~Managed Personnel (CMP) Systen, then Personnel 


Management System (PHS), and then Versatile Training System 
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wrs). The Naval Air community currently uses ATSS; the 
Submarine community uses the VTS identification; the Reserve 
community named their adaptation RTSS; all systems have the 
same ktasic configuration. 

The Digital Equipment Corporation (DEC) PDP- 11/40 
computer was selected as tne initial mini-computer for CHP. 
Ordered in late 1971, it was procured through a competitive 
contract as a turnkey training device, i.e., the contractor 
waS responsible for all installation, and only had to "turn 
the key" on before handing it over to the Navy. The systen 
was exempted from the complex and lengthy Automatic Data 
Processing Equipment (ADPE) approval cequirements by the 
Chief of Naval Material because it was designated solely a 
training device. The test and evaluation was done for 
VA-122 and two other operatioral A-7 squadrons. The 
computer was installed in mid-1972. The LTV software devel- 
oped in Dallas was used, with software development contin- 
uing on-site. Data and operating files were generated for 
FRAMP and the operational squadrons. Evaluation of the 
prototype was successfully completed 7130) ey 2a. 
Administrative perscnnel from other Naval Air activities 
visited the CMP at NAS Lemoore and were given a demonstra- 
tion of the systen. 

CMP's name was changed to PMS during this time. U0 
December 1973 the Naval Weapons Center at China Lake took 
control of cdevelopment and implenentation of the project. 
Its job included: 

1. Anticipating the training needs of the various Fleet 
activities. 

2. Observing and evaluating training methods and proce- 
dures both before and after installation. 

3. Determining the expansion required to maintain a 
satisfactory ievel of training readiness in all areas 


Supported by the systen. 


13 


By 1975, the system was deSignated ATSS for management 
CONLLOL, and the Weapons Center still holds development 
control over the ATSS software. 

A hardware upgrade to the PDP-11/70 followed, allowing 
expansion of the 101 data items to 509, and Signalling the 
advent of Version Two of the software. The original file 
structure became inadequate. Version Three software design 
began in 1976 at five operational sites. The intent was to 
eliminate some redundancies and clearly differentiate sepa- 
rate functional areas into subsystems. A phase-in approach 
was used for Version Three design and development. This 
substantially increased the capabilities of the system, but 
failed to achieve the total integration reguired. It lacked 
the flexibility needed as the uses of the system gradually 
expanded. Thirteen subsystems have since evolved from these 
beginning efforts; Version Four of the software was designed 


to solidify and integrate these subsystems into a functional 


and expandable system incorporating a Data Elements 
Dictionary, easier fFrogram maintenance procedures, and a 
more accurate software configuration control. At this 


writing, version four software was still under development. 
Large ATSS sites were upgraded to the VAX-11/780 CPU, a 
32-bit machine capable of a 4-gigabyte program address 
Space. The same RSTS/E operating system was used instead of 
the more versatile Virtual Memory System (VMS) operating 
System designed specifically for the VAX-11/780. RSUS7 8 
burdened the normally efficient VAX computer and these ATSS 
Sites did not realize a significant increase in computing 
performance over the old PDP 11/70's. All attempts to 
improve the RSTS/E software so it would not diminish the 
VAX's efficiency failed and NAVAIR finally returned the VAX 
computers for more PDP 11/70's. NAVAIR intends to keep the 
RSTS/E operating system and attempt to improve it until it 


1s efficient enough for the VAX. They have decided on this 
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route because all of the ATSS(and RTSS) software is tied to 
poo / E. 

Due Lng Fiscal Year 1978, the Office of the Comptroller 
of the U. SS. Navy (NAVCOMPT) reviewed the ATSS exemption 
Status and ruled that ATSS was nota training device as 
defined by Department of Defense/Department of the Navy 
budget policy. NAVCOMPT and CNO reclassified ATSS as a 
computer-assisted TE. Grebo abaya system within the generic 
category of equipment configured solely for training appli- 
Gat lons.. NAVCOMPT authorized continued appropriation of 
ATSS hardware and software via Naval Aviation Procurement 
funds (AEN), predicated on ATSS beiny used solely for avia- 
Mmrome training applications with no other expansion GCapabili- 
ties in the future. 

A Naval Audit Service study completed in 1980, [Ref. 1], 
found ATSS development and acquisition generally satisfac- 
TO iy. Iwo areas were mentioned where improvement could be 
made: | 

1. Opportunities exist for reducing costs by benefi- 
Cially employing ATSS hardware and software for 
requirements of other reiated information systems and 
by manning operational sites with government vice 
contract employees. 

2. improvements can be made in fund administration and 
in the integrated logistic support areas of planning 
Giemeconriguratlon=cortrol. 

The study determined that CNO's refusal to expand ATSS 
was based on the perceived need to maintain ATSS exemption 
status under the ADPE acguisition regulations. iro und 
also that this exemption is no longer needed, because the 
final 10 ATSS software systems to be purchased were ordered 
imdes a FY 1980 contract. The general conclusions stated 
that the benefits of expandiny the inherent capabilities of 
the ATISS software to allow for additional field uses would 


iS 


be more cost effective than a brand new system could 
initially provide. This is the first of many instances 
where outside agencies recommended that the ATSS/RTSS family 
be expanded to include more than just its limited training 
application. These agencies have recognized that training 
is only one step towards achieving the organization's goal 
and that many other functions should also be automated. CNO 
concurred with the findings of the study, [{ReEf. 1: p.19], 


with a lesser degree cf urgency than implied in the study: 


ATSS, aS it exists today, meets the intenme and Sscopcmcr. 
an automated information system and should be managed 

developed, acquired, and funded under ADP rules an 

regulations. However one polnt Must. be emphasized 
Regardless of ATSS status, 1t remains to be determined, 
through detailed feasibility studies and economic anal- 
yses, to what extent other systems can be accommodated 
and Savings achieved without degrading the primary func- 
tion of providing highly trained and qualified fleet 
replacement personnel for the aviation community. 


CNO will take the eet | pec een to remove the ATSS 
a 


exemption from ADPE regu 10ns consistent with an 


orderly transition scheme so as not to disrupt ongoing 
ATSs C@eomncr 


ATSS is now finally under the ADP umbrella, and is using 
OPN dollars for funding. The transition of the ATSS Program 
from the Naval Weapons Center to the Navy Management Systems 
Support Office (NAVMASSO) should start ain SEY 85, with 
NAVMASSO pickine up responsibiiities for contracting and 


software development. 


Be RISS 


The Chief of Naval Reserve became interested in ATSS as 
a viable training and administration tool for its activities 
as Carly as T9772 ATSS was chosen as the most  cost- 
effective method to achieve its required personnel training 
and training management support. JUStifteseon tor ie 


Selection was that it would align the Naval Reserve with 
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Srgoing USN training initiatives and provide compatibility 
with a standard active duty computer systen. ieeard Cane On,, 
some cost avoidance would be realized from the sharing of 
resources when active USN and Reserve aviation activities 
were co-located at existing ATSS sites. Further savings 
would be realized by adopting an already existing system and 
avoiding the time-consuming and expensive systems develop- 
ment process. 

For funding and control purposes the system was renaned 
the Reserve Training Support System (RTSS). It consisted of 
three major component systems: RTSS(TM) for training manage- 
ment, RITSS(Surface) for surface/ashore, and the RTSS (Air) 
moweeaviadtilon.  CNAVRESINST 5230, [Ref. 2: p. 1], established 


policy for the development as foilows: 


The Reserve Training Support System (RTSS) is an auto- 
mated training, managenen pn ea _systen. The purpose 
Or the system 1S to provide training management support 
to field Naval Reserve training administrators and to 
1ncrease the Meaty rox eee ad Pedultess intorpation 
reporting at all Naval Reserve ommand levels, A dual 
systen pean will provide for_a field training system 
piste rOlre OL Naval Reserve field administrators anda 
peaitoua Training Management System in support of staff 
unctions. 


1. RISS (Aix) 


The component of RTSS known as RTSS(Air) is designed 
to support personnel training and training management at 
aviation activities--NASs, Naval Air Reserves (NARs), and 
Reserve Forces Squadrons (RESFORONS). This includes active 
duty as well as drilling Reserve personnel. The system was 
designed to support multiple training needs--formal schools 
Paedrais, On -the-JOp—Trainingyeainittwal training for Ready 
Mariner (RM) personnel, refresher training for veterans 
gained to the Naval Reserve after leaving active military 


service, and combat-ready training for RESFORONs. fe 4s 
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designed to be capable of creating a trainee’s training 
record or acquiring an existing record from another AMTSS5 
Site when the trainee initially enters the Naval Reserve, 
maintaining an individual's training record, and monitoring 
the training jnistory/requirements throughout the individu- 
al's entire service in the Naval Reserve. RTSS@Aixr) Muerte 
also provide sommunications capabilities to support activi- 
ties nationwide. This includes aviation activities at any 
of eight Reserve NASs, seven NARs, and active NASs. It is 
supposed to have the flexibility to support both remote and 
local users via several methods: dial-up, dedicated communi- 
cations and batch updating through exchange of information 
with a remote Minicomputer, word processor, or intelligent 
terminal. The long term objectives of RISS (Air), [Ref. 2: 
Dow) pare, 

a) An increase inthe quantity and guality of Selected 
Reserve (SELRES) mobilization billet assignments at 
all command levels. 

b) Integration of personnel and training record data 
under a single system accessibie from remote 
locations. 

Cc) keduction of time and training resource requirements 
through individual SELRES diagnostic testing; training 
scheduling, tracking, and reporting; individualized 
IVStENet ion and maintenance and administration of 
syllabi and courseware. 

d) Reduction of time required for, and increase in accu- 
racy of, development of data for mobilization. 

e) Monitoring personnel readiness status. 

f) Improvement in the effectiveness and efficiency of 
tracking trainee progress. 

g) Improvement in the reliability of training information 


at all command levels. 
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h) Reduction of administrative and clerical worklcad of 


PLeid ss State, and Operating units. 


Pee Rss | 


3 


M) 


fhe seks Se(T M) waS designed to support training 
Management, mobilization assignment, readiness measurement, 
and mobilization and readiness reporting. ike REISS (Ame), 
it was to have the capability to create an individual's 
record when initially affiliated with the Naval Reserve and 
then to follow him/her throughout the reservist's entire 
service with the Naval Reserve. The long term objectives of 
foe System, {kef. 33; pp. 2-2,2-3)}, overlap those of RISS 
(Air) considerably: 

a) Increasing the quantity and quality of Selected 
Reserve mobilization billet assignment capability at 
alli command levels. 

b) Integrating personnel and training record data under a 
Single system accessible from remote locations. 

Cc) Providing a methodology for the real-time measurement 
and reporting of personnel training readiness. 

d) Increasing the efficiency and effectiveness of sched- 
uling training for the drilling Reservist. 

e) Providing more timely and accurate information for 
mobilization reporting. 

£) Improving the reliability of training information at 
all command levels. 

g) Reducing the administrative and clerical workload of 
operating units. 

h) "Capturing" input data at the source, thereby elini- 
hating intermediate error-inducing steps. 

1) Providing limited stand-alone local processing capa- 
bilities for the Naval Reserve Center. 

j) Providing an inteyrated communications capability 


enabling the localized units to exchange/update data 


ie 


with the CNAYVRES RISS (TM) centralized data base and 
other RTSS (Surface) units. 

Seven years ago, the long term goal was for total 
integration of RTSS (Surface); RETSS (Air), anak too eee 
into a consolidated and centralized database to provide 
real-time information fOr personnel, mobilization, 
recruiting, readiness and training management. At present, 
the RTSS (Air) and RTSS (TM) are two separate systems 
running on two separate PDP 11/70 computers at New Orleans. 
Personnel data from the field must be entered twice in order 
to keep data on both systems. Much of the data, and resul- 
tant inaccuracy, for RTSS (TM) has come from its dependence 
on " the Inactive Manpower And Personnel Management 
Information System (IMAPMIS) for billet and mobilization 
queries. IMAPMIS 1s acknowledged to be inadequate, andis 
presently under extensive redesign! [Ref. 4: p.1-T4]. 

informal correspondence with the RTSS coordinator at 
New Crleans indicated a hopeful union of the three RITSS 
systems within a year by the new contractor, Martin-Marietta 
COED. At the same time, however, he acknowledged that once 
the DEC/VAX 780 equipment arrives, all the software would 
need to be designed away from the RSTS/E operating systen, 
and a database more powerful than the locaily designed but 


obsolete one in use would need to be implemented. {Ref. 5] 


.'See also Chapter 3: PROBLEMS, Naval Reserve, un 
Teepe MGS SMe es: Programs discussion, and STRA 
under the SDS discussion. 


Ze 


ce APPLICATIONS SOFTWARE 
ie TSs (Air) 


The applications software for RTSS (Air), as derived 
from the original ATSS programs, is divided into the 
following categories: Personnel Qualifications, Report 
Generation, Test and Evaluations (TEVS), Poighites, Data, 
Personnel Scheduling, Enlisted Training, Aircrew Training, 
and Resource Configuration and Scheduling (RCAS) [Ref. 2: p. 
Tj. A brief explanation of each follows: 

a) Personnel Software--the cornerstone of the RTSS (Air) 
database, with personal identification and training 
history data for individuals. 

b) Personnel Qualification Standards (PQS)/Qualification 
Software--outputs listings of personnel qualification 
for specific tasks and the expirations of those quali- 
fications; not operationai at this writing. 

c) Report Generation Software--a variable report gener- 
ator to provide users with the capability to retrieve 
records based on a specified selection criterion, sort 
or arrange these records in any desired sequence, and 
generate reports with selected data items from the 
record. 

d) Test and Evaluation Software--provides the capability 
to create, update, review, and delete individual test 
items and generate printed tests, and provide optical 
scoring and statistics generation. This sub-system is 
not operational at this writing. 

e) Flight Data Software--allows the entry of yellow sheet 
data for statistical reports on aircraft and aircrew 
flight times. 

f) Personnel Scheduling Subsystem--matches a student's 
education and experience with the needs of the service 


and the available training paths to meet those needs. 
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This sub-system waS not operational as ’er June ae 

It wiil utilize two Separate software components: 

i) Enlisted Training Software-~individual  crainane 
records and schedules for training syllabi. 

ii) Aircrew  Software--individual aircrew training 
records, schedules for student training with 
Start/stop dates, and long term trend analyses to 
detect deficiencies in the training proggam 
itself. | 

g) Resource Scheduling Software--types, quantities, and 
status of training resources. It matches training 
resources to training needs. 

h) Resource and Configuration Accounting 

Soitware--monitors status and configuration Git 

training aircraft resources. It provides the cCajpa-= 


bility for individual aircraft maintenance records, 


and generates all required periodic maintenance 
reports. 

At present, only the Personnel and Resource @ 

Configuration Accounting Software are operating. The 

Testing software is close to implementation. Another 


subsystem not directly included in the original Functional 
Description, Reserve Training Tracks, iS presently being 
developed to map billet training requirements to an individ- 
uals background and then schedule nim/her for available 


schools in an individual training, teace 


2. RISS | 


TM ) 


The RTSS (TM) software consists of eleven systen 
functions, [Ref. 3: pp.3-5 to 3-18], in various stages of 
development at this time: 

a) Personnel File Maintenance--allows ‘for review and 
update of records by individual or by unit. This 
Subsystem is linked to IMAPMIS, MATTS, and the ACDUTRA 


1A Ue 


D) 


Cc) 


d) 


e) 


g) 


h) 


Ly, 


order writing systems for accurate data. fees pres- 
ently independent of RTSS(Air) Personnel software. 
Billet File Maintenance--allows for review of indi- 
vidual or unit billets, and updates of Individual 
Readiness Assessment Designator codes for either indi- 
viduals or units. It is supposed to be updated via 
IMAPMIS, and maintained via MATTS. 

REtiavity File Maintenance--allows for review of 
reserve and active activities by different codes 
(RUEG, APC, AULC), and update obpy RUIC of reserve 
activity files. It is to be updated monthly by 
JUG gag Bil ay 

Hobilization Assignment Trainee Tracking Systen 
(MATTS)--records gains, losses, transfers, and reas- 
Signments via the three previous subsystems. 

Ready dAariner--tracks the flow of Ready Mariner 
personnel through the Naval Reserves. 

Variable Report Generator (jJuery)--enables users to 
develop and generate reports or reguests for informa- 
tion from the database on demand. 

Fixed Reports--enables the user to generate certain 
preprogrammed fixed reports, such as readiness. and 
mobilization reports which cannot be met through 
Query. 

Utilities--a collection of software modules for auto- 
mating labor intensive manual operations, such as 
producing mailing labels. 

ACDUTRA Request Tracking Systen (ARTS) -- provides 
authorized users access to the RTSS(TM) ACDUTRA appli- 
cation files to create, update, review and delete 
applications and to generate approval, disapproval, 
cancellation, and quota request letters concerning 
these applications. It is also to provide access to 


the Course Files with review capability for standard 
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CANTRAC and MCRF courses, and create, delete and 
review capability for non-standard courses. 

j) Readiness--allows for IRAD billet input, update, and 
review by unit, Reserve Program Number (RPN), rating, 
or designator, and generates diary entries for posting 
to IMAPMIS. It is linked to the Billet Maintenance 
subsysten. 

k) Mobilization--the primary communications vehicle for 
reporting guantitative unit mobilization data and unit 
status information in the event of an actual mobiliza- 
tion or mobilization exercise. It is a subset of the 
files created by the Billet and Active Activity files, 
and is supposed to be updated after e2very billet 
update. 

As of December 1984, the only subsystems fully oper- 


ational were MATTS, ARTS, Readiness, and Ready Mariner. 


D. SYSTEM SOFTWARE ENVIRONMENT 


Computer programs in RITSS systems must interact with the 
DEC Resources Sharing Timesharing System/Extended (RSTS/E) 
operating system. RSTS/E is designed to allow up to 64 
Simultaneous processes? to interactively access large 
amounts of data. Tt dynamically allocates processor tine, 
memory space, file space, and peripherals to suit the 
changing demands of the systen. Development to date has 
been in the BASIC-PLUS and BASIC-PLUS-TWO programming 
languages; RSTS/E can also support COBOL, FORTRAN IV, APL, 


and REG iI language processors. 


“In a silagle processor environment such as this, the 
term "simultaneous processes" means that the system. can 
handle separate user processes with no appreciable delay 
Such that the user thinks he is the only one on the system. 
in actuality, if a large number of userS were to attempt to 
run Simultaneous processes, there wouid be a delay on the 
order of several seconds. 
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E. SYSTEM HARDWARE ENVIRONMENT 


mic ObC fama, Of PDP—-il Computers 1S wsed at RTISS sites 
in New Orleans and other non-ATSS sites. The PDP-11/70 is at 
New Orleans, and either PDP-11/23 or 11/50 CPUS are at the 
smaller sites; specific details of each site configuration 
are available in the Functional Descriptions of the R1TSS 
systems. The follow-on generation to the PDP-11, namely the 
VAX-11/780, is being requested in the POM 37 for the New 
Orleans RISS(TM) site. Code 46 (ADP Plans) at CNAVRES is 
guiding the purchase under the umbrella of Navy ADP 


purchasing requirements. 


F. PROGRESS TO DATE 


RISS (Air) presently consists of four Commander Naval Air 
Reserve Forces (COMNAVAITRESFOR) central sites, each of which 
support a number of satellite sites. The central (host) 
sites are geographically spaced to serve the largest number 
of aviation activities. En addateen to the centrai and 
satellite sites, Reserve aviation activities are co-resident 
on seven Regular ATSS sites. 95% of all participating units 
were to be supported by the end of calendar year 19384 by 
Semener RISS(Ailr) or ATSS. [Ref.6: p.1] 

Gwing to its borrowed and aged nature, RTSS(Air) has 
several drawbacks to effective itsplementation in the field. 
Since it is tied so ciosely to ATSS, RTSS implementation 
suffers any problems that ATSS is susceptible to. NAVAIR 
Support of the ATSS system has finally increased to a staff 
of three after many years of requests. Moreover, the 
initial premise in the RTSS (Air) Functional Description was 
that no software modification costs would be incurred by the 
Reserves because of the link to ATSS. This is faulty on two 
counts. First, while the Reserves wait for updated software 


instead of wodatinGg  1t themselves, thev incur the 
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quantifiable dollar costs and non-quantifiable readiness 
costs of maintaining dysfunctional or manual systems. 
Second, even when the software is received, it requires some 
massaging to rit the Reserves own unijue needs. The Fiscal 
Year 1984 Reserve budget allowed for little else than main- 
tenance of software; the Fiscal Year 1985 budget was cut in 
half, but will allow for some improvement. 

A new contractor, Martin-Marietta Corporation, ats} mabey 
place as of the beginning of Fiscal Year 1985. Software 
development and hardware installation efforts for ATSS/RISS 
were abridged appreciably during the contract negotiation 
and letting process from July 1983 - September 1984. 
Periodic continuance renewals of the previous contract with 
the Syscon Corporation served only to keep a maintenance man 
on at existing sites, but delayed needed consulting and 
development services. 

Other difficuities include the delays that the Naval 
Weapons Center is experiencing in getting the new version of 
RSTS/E implemented; it seems that Martin-Marietta does not 
have the appropriate maintenance contract with Digital 
Equipment Corporation for operating system updates. Also, 
@s a result of drawn-out contract negotiations, there are 
three month delays before software changes can be issued 
tnrough the new contractor. Additionally, the ATSS software 
Stiil cannot track personnel at changing sites.3 

Emphasis for implementation of the RTSS program through 
1984 by CNAVRES has been in procurement and installation of 
hardware and peripherals at the various. sites. This 
emphasis 1S now shifting toward bringing software on-line 


and beginning user training. Implementation has been slow 


SWe found an. ironic anecdote in our ATSS gee oun 
research: according to the minutes of the September 84 ATSS 
pee gueerton Advisory Board Meeting, several users volun- 
teered their services to NAVAIR as model managers in evalu- 
ating ccmmercial off-the-shelf software. Somebody beat us 
to the punch, at least in spirit. See [Ref. 7: p. 2]. 


PS 


due partly to the newness of ADP to the Reserves, but more 
so to the annual funding constraints and contractor negotia- 
tion problems of MESS: At this writing, a development 
hiatus of several months caused by a major budget slasaing 
of contractor support has finally been cleared up; CNAVRES 
is slowly forging ahead. 

Networking capabilities from field sites to New Orleans 
are still in the planning stages. While a@ was initia, 
hoped that a DEC product known as DECnet would serve as an 
adeguate off-the-shelf candidate for the interface software, 
development and implementation of the Defense Data 
Network (DDN) have precluded a stand-alone network. 
OPNAVINST 2070.4 of 7 March 1984 has mandated that ADP 
systems requiring lony haul data communications include 
provisions for using the DDN as their primary data communi- 
cations medium. Attempts by CNAVRES Code 46(ADP Plans) in 
mid-1984 to waiver RTSS from this Defense Communications 
Agency requirement were unsuccessful. Code 46 has since 
been investigating the necessary means by which to comply, 
including soliciting bids for protocol conversions for the 
RSTS/E, RTSS, and DDN interface. 

In addition to the above software and hardware problems, 
we uncovered Many deficiencies in computer support. 
Specifically, no clearly written users manuai was or iS now 
in existence for RTISS (Air). No funding for revising, 
updatiny, editing, or rewriting the old, existing manuals is 
available at this time. The instlruceeuonce Ranuals, ‘and 
Minutes of meetinys that we read in our research stressed 
that RTSS(Air) is a training system, placed in the field for 
the benefit of the user; usage is limited to training 
oriented subjects, and any use which cannot be directly 
related to the training of aviation personnel cannot be 
Supported on this system. The assertions were unclear given 


that ATSS is now under Navy ADP guidelines. 
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Other specific problems witk the RTSS system(s), aS seen 
by the users and the experts, Will be addressed with the 


larger issues of AIS management in the next chapter. 


DL, 


III. AUTOMATED INFORMATION SYSTEMS 


A. INTRODUCTION: THE VALUE OF INFORMATION 


The Naval Keserve is the recoynized backbone of a strong 
mobilized nation when all-out war occurs. It iS now wres- 
tling with the nontrivial questions of meeting distributed 
real-time personnel and mobilization information requests. 
in its information processing arena, however, it faces many 
of the endemic organizational problems of a still young 
computer age: lack of an implemented top down design 
strategy, and possession of antiguated hardware and soft- 
ware. The software for its RTSS (Air) project, derived from 
the initial Aviation Training Support System, was developed 
in an era when computers were used only for data collection, 
processing, and storage. Used only as a computing device, it 
had limited strategic management value; at that time there 
waS ho intent for a correlation between strategic objectives 
and computer system utilization. Its value as a decision 
Making tool in helping to evaluate training and mobilization 
readiness was and is extremely limited. 

Today information is a powerful tool that influences the 
health and well-being of all organizations, government or 
business. Members of a 1983 blue ribbon panel appointed to 
study the Navy's utilization of automatic data processing 
equipment unequivocally stated: "Virtually every action by a 
commander, manager, or administrator in the Navy, as in any 
large organization, involves the acquisition and under- 
standing cf information: information about the organization, 
about its status, about its resources, about its environ- 
ment. His actions usually result in the creation and promul- 


gation of policies and directives." [Ref. 8: p. 2] 
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Information is a Key resource in both the develorpnent 
and execution of organizational strategies. In this context, 
it is essential to develop an information system based on 
the strategic objectives and direction of the organization 
Baer. Js pe 39). While it is the task of the lower levels 
of the organization to collect data and organize it ina 
meaningful form, it is the role of the strategic planners to 
define the scope of the desired information. 

The use of computerized information systems has greatly 
aided the collection, compilation , and presentation of data 
and information. The collection process is no ionger a 
eet icult or costly task. As a result, there 1s a prolifer- 
ation of available data that must be converted into useful 
information and analyzed. Managers at different levels of 
an organization reyuire different information. Managers 
must be able to extract information relevant to their realn 
of decision making. Information management must emerge as a 
Simic ical discipline LOne all organization's strategic 
decision-making process. 

Information Management must be an aggressive program 
that presents the correct amount of substantive information. 
in dealing with the volume of information, more information 
will enhance decisions up to a certain point; beyond that, a 
law of diminishing returns sets in. To gather the correct 
amount of informaticn, Managers must understand how to 
erfectively use current and predicted future technology. 

For the remainder of the chapter we will address this 
technology issue and some specific problens, past and 
present, for the Navy and Naval Reserve, and present the 
latest Information System Strategic Plans for the Navy and 
the Reserves. We will present a mixture of design (rede- 
Sign) strategies to cope with design problems, and recommend 
a State of the art problem solving approach that we found 


viable, functional, and relatively immediate. 


an 


B. PROBLEMS 


ie 


ies 


val Reserve 


The onslaught of new computer technology in the last 
20 years remains clearly in the headlines. Unfortunately, 
the depth to which this advancing technology can permeate to 
the field level in agencies as large and complex as DOD or 
the Reserves is constrained by educational, fiscal and 
bureaucratic methodologies that stifle initiative and reward 
Stagnation and the status quo. A January 1984 study, 
Analysis of Naval Reserve Force Information Systen 
Management Requirements, was both blunt and specific in its 
cited problem areas and recommendations. The list of prey- 
lems could be a primer for a ‘what not to dot Information 
System reference book. 

BLES, they saw no single organization taking 
responsibility for the automated information systems in use 
by the Naval Reserve. Many of the systems are the result of 
"favors" or "“hand-me-downs" from others, and in most 
respects not well-designed for Reserve use because they were 
never intended for this community. The lack of account- 
ability resulting from AIS functional sponsorship of Reserve 
systems by other commands has been a major contributing 
factor to the current inadequate state of Reserve informa- 
tion systems. [Ref. 10: p. 2-3] 

Second, the bureaucratic headache of Life Cycle 
Management resulting from the Brooks Act of 1965 and subseg- 
uent directives addresses only the issues of AIS acquisition 
and deveiopvment plans. The need to view information aS a 
resource 1m an overall Information Systems Management Plan 
ise Lacking, 

Third, current Reserve AISs do not get the job done. 
They do not contain all the data needed for desired mnoni- 


toring and control functions. They do not provide for easy 
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information retrieval in desired formats. They currently 
contain duplications of data, with inconsistencies in defi- 
Mition processing and data entry which lead to confusion 
and/or inaccurate measures of effectiveness. The present 
systems were developed mostly during a period when available 
hardware and software were more expensive and had less capa- 
bility. They were usually a response to a crisis Management 
need and often developed with virtually no user interface. 
faec. (03 p. 3-71} 

HOUbtO ee ctarreprOoLtcrency in ALS planning and lead- 
ersnip was nonexistent. In the finding's woris: "So if the 
distributed architecture...recommended...is to become a 
reality, it is through the 'hands on' involvement of line 
management on the staff and in fieid activities" [Ref. 10: 
aoe 3-5 |e Effective use of new hardware and software tech- 
nologies guided by proper application of information 
resource management skills must be the approack for the 
leaders of the 80s and 90s. 

Among several specific organization realignment 
suggestions, a fifth and major recommendation was for the 
development of a long range technical architecture for 
information systems [Ref. 10: p. 4-6]. It is to be based on 
a distributed model whose major components are: 

a) Electronic workstations 
b) Distributed computer system hosts 
c) An advanced electronic data network 

Perhaps the strongest and most important recommenda- 
tion the study put forth was to adopt as a goal for long 
Tange planning purposes "the ability of all members of the 
Reserve claimancy to accomplish their assigned tasks with 
the assistance of automated information systems" [Ref. 10: 
pe 4-2]. 

To illustrate the concept of information as a 


resource in the Reserves, some examples of present day 
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eifectiveness are pertinent. In their preliminary draft of 
an Information Systems Plan for COMNAVRESFOR, tae team noted 
deficiencies of various Automated Information Systems as 
they related to functionai needs. Among then: 


a) Fleet Programs 


The total picture of I.S- use in Fleet Prograns, (ecm 
equally in Logistics/Shore pore Programs and Staff 
Programs, is one of solutions to information needs, and 
partial redundancies and dissatisfaction with the accu- 
Cacy, timeliness, format and ultimate usability of the 
information received. fhe Gominant perception Cur oa 
the 31 and 32 divisions <Programs and Training Support> 
is expressed in the remark oi one Program Manager that 
‘much of the time we seem to be working or the 
computer rather than the computer for us'*. [Ref. 10: 
Appendix 4-46 


b) Logistics/Shore Support Programs 


RTSS(TM), used for such purposes as_ obtaining biilet 
listings. to determine allowances and field inquiries 
about billets as well as for addresses and address 
labels, is less than Satisfactory as a provider aa. 
required data. Iwo program Mahagers in fact try ae 
Minimize reliance on it due to unavailability or the 
sorts most useful in program management (e.g. alphabet- 
ical by type of unit), and the system's slowness. The 
hand sort which two progean managers presently revert to 
takes ap Ee uaa our hours. A program manager who 
does, rely on RTSS(TM) counts ona one-day delay to 
receive requested output. since that Often 15 Ret sear 
enough for fielding Senior's inguinpzes, Sone resulese. 
that reat volunes of ees are kept from which to 
enerate manual reports. ode 37124 relies for much of 
heir data on a refort Se cee outside the organiza- 
tion a NAVSUP report which aggregates manning data on 
NAVSUP-supporting units, Since it is wore accurate and 
imely. 


A further shortfall in RTSS(IM) at present is that some 
data fields are not or are meee cece! updated. (for 
Sees educaticn, address and telephone numbers). 
Fields that are never u dated would better be removed 
from the re ale altogether, in some officers' estina- 
tion, in that wrong data often are more deleterious in 
een usa than Noe data sac a lin. {Ref. 10: Appendix 
a es 


CG), Stabe eeograls 


= a = 


Lack of accuracy and completeness are a continuing 
problem, with monthly reports (rede ly at variance 
with manually maintained figures by 20% or more....Short 
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term emergency mobilization needs, such as Grenada and 

Lebanon essentially must be managed with manual tech- 

nigues due to lack of responsive terminal facilities and 

4435-50 7° mobilization database. [ Ref. 10: Appendix 
a 


d) Flight Support 


The RTSS(Air) software is behind the times in format and 
content - content too old for flight reports. The time- 
liness of these content data wiil be enhanced through 
modification to process. 

Code 55 <Flight Support> has a need to transfer informa- 
tion from syStem to system in a rapid manner _ to facili- 
tate management . decisions. This need affects 55's 
managerial effectiveness. 

An example of this sort of concern is the inability of 
55 to gain access to requirements except NECS which 
helps but an individuai'ts @xperience is the more impor- 
tant access so far as readiness 1S concerned. [Ref. 10: 
Appendix 4-52 


2- Navy 


The Navy did not escape the scrutiny of close obser- 
vation of its ADP sins. The blue ribbon panel funded by the 
National Research Council found that the entire Navy was 
operating with "computing equipment produced in the 1960's", 
and too little attention being paid to “policy development 
and Gliuadteglce planning... <and> to the potential Oi 
management-level information systens" [Ref. 8: Dp, |. 
The panel published a number of findings ina narrative 
foraatted ten page chapter of the report. The following 
points are pertinent to the kKeserves' implementation and 
expansion of a 14 year old borrowed system, and are quoted 
verbatim from the report: 


a) Hardware 


Many problems arise when obsolete equipment is allowed 
Pomreiain th Operation. aL GiS pe tne cost of operation 
and maintenance is much higher for an early-generation 
machine, compared to tha £05, da  CWETeNt- Jeneration 


system of equal capacity. savings in energy, floor 
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Space, and maintenance can usually Repay the purchase 
cost of a new central processor in less than two years. 
Reliability and Fepairability 918 # far superior eeeos 
current-generation equipment. Policies that encourage 
reusing Old equipment do not properly recognize these 
potential savings. 


b) Software 


A more difficult concept is_ that software becomes obso- 
lete just as surely as does equipment. Equipment 
replacement 1S usually viewed aS a. modernization 
project, necessary to improve reliability, _maintain- 
ability,and OP era ae But mwogermizang fe bnent gene and 
failing to. question whether software 1s also obsolete 


really addresses only a part of the obsolescence 
problen. 
Early-generation software systems were buat as 


outgrowths of manual record-keeping systems,...<and> 
were expected to produce reports, update seguential 
files...,and perhaps punch cards...The early computing 
equipment was not designed to. permit remote access to 
files; and often even if it employed random-access 
storage devices, these were often not managed by a data- 
base Software. 


When early-generation software 1s rehosted on_ a nodern 
Seu pl can System, important capabilities of the new 
equipmen are left unexploited. Furthermore, the 
requirements for an applications system do not remain 
fixed; they change over time--either from external pres- 
sures to modify a function or incorporate a new one Or 
because a better way has been found to perform the func- 
tee@ Me When a system is modernized, users should seri- 
ously question whether the software systems are still 
relevant to their information needs, or whether new 
software should be designed to exploit the capabilities 
of the new equipment. Thus, by incorporating new soit- 
ware that permits on-line access to a current database 
instead of an. older system of numerous batch-updated 
programs, the jobs of clerks and managers could be rede- 
Signed, perhaps greatly reducing errors and operational 


costs. The ES ne _software system may _be more 
useful, more efficient in terms o£ labor and machine 
resources, and truly exploitive of the equipment on 


Which it Guns. [Ref. @= ppomi0-a1 


Cs STRATEGIES 


The Chief of Naval Operations has not turned a deaf ear 
to these findings. OP-01, as functional sponsor, has dele- 
gated overall management of the Manpower, Personnel, and 


Training Information Systems (MAPTIS) PROGLaAN “te Or ic. 
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Commander, Naval Reserve Force is one of the six echelon 2 
commands encompassed in the MAPTIS functional community. 
The Reserves! involvement as an echelon 2 command in this 
regard is limited to those AISs specified in Memorandums of 
Agreement with OP-01; RTSS is one of those systems. 
Ret. 4s p. i111] 

The Program Objectives Memorandum for 1987(POM 87) 
MAPTIS Program Strategic Plan is an extensive work that says 
Git ne Cight things for correctang the wrongs of AIS frob- 
lems. It lays out ambitious and challenging guidelines by 
which it intends to progress for the Fiscal Years 87-91. The 
document iS moSt encouraging in tone with regard to AIS 


planning: 


The functional community's dependence on the use of 
automated informaticn SUE eae has reached a point where 
it has become. critical to MPT mission accomplishment 
(Ref. 4:3 pp. 111}. 

Paramount to insuring sound information system planning 
is a direct relationship to front-end mission planning 
[Ref. 4: pp. iv]. 

The rapid pace of change in ADP Bee age s Y must be 
Pesnace for if we are to avoid obsolescence [Ref. 4: pp. 


The plan, which provides information support goals and 
objectives to the MPT commands, is the vehicle for conmuni- 
cation and concurrence between MPI functional managers and 
MAPTIS information support managers. It has four major goals 
defined and established: 

a) Achieve an Effective and Efficient Operational Posture 
b) Improve the Management of Resources 
c) Integrate Modern Information Technology into the 
DAE iS PLogra ml 
d) Improve the Quality of MPT Data and Information 
An adjunct guideline to this document cites the DOD 


thrust to improve productivity and mission performance in 
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meeting the above goals through the application of end user 
computing technology, i-e., microcomputers. This Department 
of the Navy(DON) document encourages MAPTIS program managers 
to "incorporate end user computing technologies, as much as 
possible, into the MAPTIS Program as a cost-effective nethod 
of distributing information processing support to functional 
users." [Ref. 11: p.3] 

Getting back to the POM 87 plan, the Reserves are 
specifically singled out as one of the major challenges in 
meeting the DCNC's objective of improving fleet readiness by 
continuing to effectively and efficiently fulfill manpower 
requirenents. Along with a trained active force and 
increased emphasis on contractors and civilian employees, 
the plan cites the intent to expand the Naval Reserve over 
the next five years so that it will be able to take over 


missions from the active force. It stated uneguivocally: 


Automated information support is essential if Navy MPT 
managers are to succeed in these efforts. The ability 
to rapidly assess all elements of the total force 15S 
CEUCcia co ne ete the peacetime, mobilization, and 
wartime requirements levied on the Cau MPT managers. 
This assessment depends on guality information 1.e. 
information that 1S accuraté, timely, complete, and 
understandable. Meeting wartime information require- 
ments involves eS developing, . and aD alae 
procedures and associated data processing programs an 
equipment that will support (1) the maintenance of the 
Navy's active duty, civilian, and Reserve forces, (29 
the mobilazation of the inactive members of the Navy, 
and (3) the smooth transition from peacetime to wartime 
management of the total force. [Ref. 4; pp. 1-1,1-2] 


One of the strategic goals of the plan is for a central 
pay and personnel system called the Source Data System 
(SDS) < With a pilot site in place and successful at a 
personnel activity at Lakehurst, New Jersey, future software 
enhancements are to extend the variety of functions to mobi- 
lization, order delivery and processing, and Reserve 
personnel accounting and drill reporting. Plans call for 


CONNAVRESFOR to develop a distributed personnel, pay, "ana 
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training system by the second guarter of Fiscal Year 1986. 
Integration testing of initial Reserve support applications 
Will begin in FY 86. Software used in this consolidation of 
Active and Reserve personnel data base systems is to be 
tested in FY 86. In January 1987, SDS and COMNAVRESFOR are 
to update the implementation strategy and plans for exporta- 
feome to £Teld sites. [Ref. 43 pp. 2-3 to 2-7] 

Nonetheless, RTSS is not going to disappear soon. The 
Five Year Defense Pian indicates a requirement for funding 
through 1991. A MAPTIS budget increase of $924,000 is Leing 
requested for POM 87, all of it earmarked for the three RISS 
systems. CONtrdet Ol SUDDOLE, software conversion, and 
DEC/VAX-700 hardware are requested to support the systems 
and "migrate programs to a more current technology" [Ref. 4: 
pas 00, 3-61 }j. Code 461 in New Orleans indicated that much 
of the software conversion was expected to be jione in-house 
once the new equipment arrived. 

One area missing from this long-range plan involves 
memrming; Specifically, “training for the Officer corps. Esa 
the past computer training has been aimed at the enlisted 
person who will be operating the computers. Mitact.e asic 
computing skills are now being taught at enlisted ‘A' 
school. This is not sufficient to achieve proper utiliza- 
tion of information systems. It is the officer corps who 
Should know how to convert the vast amount of data into 
usable information. They must receive a larger portion of 
information systems training in future years in order to 
Make proper use of current technology and effectively manage 


the Naval Reserve in the rest of the 1980's and the 1990's. 


De. CURRENT TECHNOLOGY 


Tt is no wonder that the Naval Reserve has been slow to 


Pech Mological Change. Only since the latter years of the 
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Carter administration has the strategic value of a nodern 
Reserve force been translated into meaningful funding. The 
Reserves have traditionally piggy-backed the active Navy's 
procedures and systems. Computing policies and equipments 
have followed suit, including the tendency to be several 
generations behind. 

Our research found an eager but skeletal ADP staff at 
Code 46 in New Orleans. Recognizing their need for assis- 
tance in this volatile field, they immediately acted upon 
the NAVRES ADP Study recommendation to implement an 
Information Systems Support Unit (1SSU) composed of top- 
rated SELRES ADP professionals, only to have the program 
recently cancelled in the political and fiscal fight of 
mobilization vs. non-mobilization billets. The staff made a 
concerted effort in late 1984 to canvass the SELRES field 
for a selective group of gualified and experienced prcfes- 
Sionals that would meet regularly in support of CNAVRES 
information System plans and goais. No sooner did they have 
the unit selected (September) when authorization was lifted 
at budget control levels (November) on the grounds that the 
unit would have been a non-mobilization unit. 

Whatever the reason, this unit must be established. Te 
move towards implementation of an AIS without the guidance 
of these proven ADP professionals would be a grievous 
mistake. The ISSU) must provide the plan for managing the 
Reserve's resources through automation. The only way to 
adequately prepare for mobilization in the future is to 
Manage today's resources with an automated information 
system. 

There are some natural inclinations in management's 
decision whether or not to upgrade technologies. When a 
computer system has been in operation for a long period, 
Management is reluctant to move toa new technology for 


several reasons. First, the system has become imbedded in 
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the policies and procedures of the organization and there is 
considerable risk involved with this change. Second, the 
large initial cash outlays involved with developing and 
implementing a new computer system can cause managers to 
side-step the issue. Finally, there is a good deal of risk 
involved with using a new technology that has not stood the 
test of time. The traditionai approach to maintaining 
computing systems has been to minimize cost; Spending as 
little as possible maintaining existing systems leaves many 
resources available for other purposes [Ref. 13: en |< 
The current systems will be replaced only after they have 
become unmaintainable and too costly. 

Correctly applied, currert technology aiiows Naval 
commanders to approach their designated missions with infor- 
mation that: 

a) Has been collected and recorded simply 
b) Has improved accuracy 
c) Has been speedily reported, collected and distributed 
d) Leads to Summaries that are timely and to the point 
e) Has enabled both manpower commitments and costs to be 
reduced [Ref. 8: p. 3] 
Rapid progress in information systems technology has 


provided the potential for major advances in their effec- 


tiveness. But these advances are neither automatic nor 
eaSily attained. A key aingrediert for the success of 
current information systems 1S a comprehensive plan. This 


brief analysis merely frames the probiems that face the 
Naval Reserve and RTSS. The problems we have addressed have 
evolved because of a lack of strategic planning that 
includes the use of new technology in planning for computer 
systems. 

The new technology that is chosen by the Naval Reserve 
must have hardware and software compatibility. There must be 


parallel progress in both the hardware and software areas. 
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To extract the optimal performance from a state of the aime 
computer, new software must be used. The 1960's software 
would still be inefficient on the new computer and most of 
the new hardware benefits would be lost. This was most 
recently illustrated by the failure of NAVAIR to effectively 
interface the new VAX computer with the old RSTS/E operating 
system for ATSS. The same argument applies for current 
technology software installed on the old computers. Many of 
the benefits of the new software would be lost. There aust 
be parallelism in the RTSS development pian. RTSS develop- 
ment must not follow the path of ATSS if the VAX upgrade is 
implemented in 1987. 


Ee. SYSTEMS DEVELOPHENRT 


Updating or rejuvenating an obsolete computer systen, 
whether large or small, 1S a major undertakiny that must be 
managed ty personnel trained in the systems analysis disci- 
plines. With the advent of the latest generation of computer 
hardware that offers greater capacity and speed at a cheaper 
price, the selection of hardware is less critical to the 
overall success of the system development process. Hardware 
is still important. The size and complexity of the opera- 
tions beiny automated must be correctly gauged to ensure 
that appropriate hardware is acquired. But since there is 
usually less risk in selecting the correct hardware compo- 
nents, the deterministic aspect of the system's development 
will be its software. 

The software development personnel, their methodology, 
and the technology they use are critical elements in the 
eventual success or failure of the system. The ideal situ- 
ation that the development team would like to encounter is 
where the time and money allocated for development is suffi- 


clent and that management is committed to the project's 
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success. The time allocated should be a function only of 
what a reasonable estimate of the development time is and 
not linked to any internal or externai politics of the 
organization. Likewise, the money allocated should be suffi- 
cient so that the project team isn't handicapped. This is 
the ideal situation and is not likely to occur with great 
frequency. 

A situation which is more likely to occur is where the 
development team finds that most variables and resources 
have been dictated by the organization. These decisions to 
commit resources are usually driven by factors not relating 
to the software project. This usually involves the organiza- 
tion‘s management mandating the project completion date ora 
Specific strategy that leaves but a few options open to the 
developers. The development team nust strive to produce the 
same result despite factors that threaten to detract fron 
the overall quality. 

Regardless of the environment in which the software 
development takes place, it is the analysis and definition 
of the system's requirements that can create the fundamental 
difficulty for the software development tean. requirements 
analysis is the cornerstone from which software will be 
built. it is the input to the design team's effort which is 
then delivered to the programming team for coding (see 
megure 3.1 ). The effects of a poor or non-existent 
requirements analysis are far-reaching and devastating. 

The reguirements analysis methodology evolved in the 
early 1970's and was a substantial improvement in the 
previously unstructured development process. Software prod- 
ucts from that era were typically without documentation and 
very difficult to maintain. In many cases, the product did 
not satisfy the needs of the user because care was not taken 
to ensure that user and developer were in agreement. The 


software for RTSS was developed prior to the reguirements 
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Figure 3.1 Traditional Development Process 


analysis era and fell prey to these two problems (poor docu- 
mentation and not meeting users‘ needs). 

Requirements analysis can be accomplished in numerous 
ways. The traditional approach has been to identify the 
functions to be accomplished, decompose these functions into 
elementary units and provide a written document to the user 
explaining what the system will accomplish. We found no real 
requirements analysis documentation in our look at 


ATSS/ETSS, and considering when the development occurred, 
none is expected to exist. 
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One reiatively new method of developing requirements 
analysis is by prototyping the system using fourth genera- 
tion user friendly query languages. PEOGOmy, lng, as in 
aircraft development, has come to mean an example which is 
never actuaily used in service, only as an experimental 
model to display or seli operating characteristics. A soft- 
ware prototype, however, is a pilot working model of the 
real system which does not have to be discarded, but can be 
built on or changed at will. In contrast to the traditional 
software development approach which goes through lengthy 
stages of reguirements analysis, design, development and 
implementation before a product iS seen, tune output of the 
prototyping process is yeneraily a mini-version of a desired 
end product built with the close involvement of the users. 
On a limited scale, the user can see what tne system can do 
in roughly an order of time less than the traditional 
process. This builder/user team has iittle difficulty 
understanding their own output; they can simply modify those 
items they are not happy with. When the team is satisfied 
with the performance of the prototype, the development 
process continues and expands, but the system also can go 
into use. As familiarity with the system grows, the users 
themselves become the systems developers. 

The Naval Reserve can benefit from prototyping in 
several ways. The specifications that result are more 
complete because the Naval Reserve can better evaluate the 
system and tailor it to their needs. By interfacing with 
several levels of Naval Reserve management during the proto- 
type design, the developer can deliver a result that is more 
responsive to the whole organization. The strategic plan- 
ners can easily obtain the summary information they need 
while the operational and supervisory personnel will experi- 
ence more efficient data input, maintenance, and output 


overations. 
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Experimenting with fourth generation languages as a 
productivity tool is now going on under the MAPTIS strategy 
at NMPC-4 [Ref. 4: p.1-16], and.the concept of prototyping 
is receiving more attention in the Federal environment. 
Consider a December 1984 article by the Deputy Commissioner 
of the Financial Management Service, J.S. Treasury Dept, Mr. 
Marcus W. Page. In it he commented onthe Dept of 
Commerce's approach to bringing comparable resource data 
together from several bureau-level organizations. Initially 
their focus was on rebuilding the various different systems 
to produce comparable data. They moved from there towards 
one common system in each Function being shared in the 
department. Neither approach solved their data incompar- 
ability problem. They then transitioned to what they termed 
a data "bridge", in which a selected number of data elements 
from several systems were combined into a common. systen. 
Developed by a contractor in a relatively short period of 


time, it had a relatively low cost compared to a major 


rebuilding effort. While not without its problems, the 
system at Commerce has been considered a success. The key 
to its success waS in its simple consolidated data. FOr an 


agency building a selective data base, Mr. Page offered some 


sound advice: 


The real vaiue of the selected data file method that 
Commerce used is that it fills a oe relatively quickly 
and provides a common pee or know SEG that managers 
and analysts _can manipulate by downloadin sections of 
the file to microcomputers using <spreadsheet software> 
and report generatcrs. 


Virtually every new agency organized out of predecessor 
agencies has gone through the “same process of trying to 
bring together a consisfent data file of selected infor- 
mation ffom the various bits and pieces. The difference 
today is that the tools are getting better to support 
data base creation. 


Perhaps the most reasonable and certainly. most econor- 

eek en POE yan pp Rcttc to approach this Situation would 

be the following four steps. ~ 

- Define specifically a limited number of data elements 
uSing..-approximately 80 as a start. 


=e Develop 2a prototype with OnLywoasle. /LuDCtLONS: 
pete aa ut reer cror FeoLMat. j 

= Le eS and analysts play with it to determine 
user needs. 

- Add those functions common to many users and put in 
operation. 

The point is that it 1s a selected database; users will 

want different functions or will yguickly become bored 

fame at. tf tt can be kept reiatively Simple, it can be 

g yanges or replaced with small investment. (Ref. 14s p. 


The Commerce Department's Situation is certainiy analo- 
gous to the state of affairs that the Reserves finds itself 
wath RTSS and, indeed, virtually all of its Automated 
Information Systems. The nistory of mistrust of current 
AISs by those most in need of them is the most immediate 
indication that the users, not just the designers, need to 
be personally and dynamically involved in the process to 
Make the system work. As to the use of microcomputers, the 
Navy's contract with Zenith Data Systems for the Z-100 and 
Z-150 (IBM-PC compatible) microcomputers could be an excel- 
lent vehicle for integrating modern information technology 
into the Reserves AIS strategy. It would also fit in with 
the OP-16 HAPTIS Program Strategy as cited above. Piycaectk, 
the relational database product we uSe in our prototyre is 
advertised to be completeiy downloadable to an IBM-PC/XT, 
which is essentially a Z-150 with a 10 megabyte hard disk. 

On the other hand, it might be necessary to continue 
expanding a prototype RTSS system to the point where it is 
no longer simple, or perhaps there might be a desire to 
segment the database into an ad hoc part and a static part. 
In fact, we use more than 80 data elements in our prototype, 
and discuss more than the basic functions mentioned. 

Our point is that the fourth generation software of 
today, like that which we used in our prototype, is a 
powerful tool that has the capabilities to be molded into 


user oriented results. Available information iS nore 
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consistent and timely. The prototype of RTSS we have devel- 
oped can serve as a working model for tae Naval Reserve to 
develop an independent query and report oriented maragement 
jnformation system using off-the-shelf current-generation 


tecanology. 
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A. INTRODUCTION 


The purpose of this chapter is to present the Naval Air 


Reserve Prototype, the assumptions made, the issues dealt 


with, and the prototype desigr. There are numerous append- 
ices associated with this chapter. Fach appendix is a 
portion of the database design. This chapter discusses how 


we designed the database with the actual work appearing in 
the respective appendices. 

A majority of this chapter will discuss how the ORACLE 
database management system was used to implement the many 
attributes of an effective automated information systea 
discussed in chapter three. It 1S important to note that 
this prototype is only an example of how the Naval Air 
Reserve can use current technology to implement its many 
disjoint systems ‘under one roof’. We will attempt to show 
that the needs of the Reserve can be best suited witha 
fourth generation, relational database system irrespective 
of the specific commercial product chosen. The importance 
of this prototype is in the structure of the data itself. 
This will not vary greatly between products. Throughout 
this chapter, we will present the shortfails of GRACLE to 
facilitate a more informed decision for the actual systen. 
Prior to presenting ORACLE, however, a discussion of data- 
base design and the use of normalized forms is necessary. 

The computer industry has not developed one set of terms 
to define its vocabulary, so we will attempt to use the same 
term in referring to a concept or thing. 
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Be. NORMALIZED FORAS 


1, Modification Anomalies 


The design of the records for the Nawal Air Reserve 
prototype involved the transformation of approximately 600 
data fields of the cld sequential file system into a rela- 
tional database. One important aspect of this design 
process is the elimination of modification anomalies and 
data inconsistencies. Modification anomalies occur when 
Changing or modifyinag data yields unexpected results. 
Additionally, most incidences of data duplication are elimi- 
nated. Data normalization is the method of accomplishing 
this. Normal forms are the means by which data normaliza- 
tion is done. 

To adeguately explain how we arrived at the proto- 


type design in Appendix A, we must first present the normal 


forms in database theory. We used five principal normal 
forms [Ref. 15: pe. 120). There are numerous articles on 
normalization which expand on the five normal forms. These 


include domain key/normal form{Fagin} and Boyce-Codd ncecrmal 
form [Ref. 16: p. 288]. To explain the normaiized forms, we 
found that normal forms one througk five as presented by 
Kent are the most ioyical and understandable. 

Normalized forms provide guidelines to the database 
designer that eliminate errors and data inconsistencies in 
the final design. These guidelines are in the form of 
progressive design steps that methodically transform a 
coilection of data fields into a database free of modifica- 
tion anomalies and data inconsistencies. Normalization is a 
stepwise refinement of the tables of a database. 

The culprits in database design are modification 
anomalies and data inconsistencies. There are two major 
types of modification anomalies--insertion and deletion. 


Insertion anomalies occur when we cannot insert a fact about 
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Ome Gata entity without first adding a fact about another. 
A deletion anomaly occurs when facts about one entity are 
lost when a fact about a different entity is deleted. These 


two anomalies are illustrated in Figure 4.1 and Figure 4.2 


| 
| 


Student Activity Record 


| 
| 
| ee) meni a [PEE | 
| 100 | Skiing | 200 | | 
i 150 Swimming | 5110, | | 
175 | Squash 50 | | 
| 200 | Swimming 50 
Ss et ee ee 
| 
[Ref. 16: p.j 287] | 
an 

Figure 4.1 Modification Anomalies (uncorrected) 


We have chosen a very common example to explain how 
these modification anomalies occur and how they are eiini- 
nated. In Figure 4.2 there 1S a table to collect inforna- 
tion on students(by Student Identification Number - SID), 
the extra-curricular activities activities, and the fee for 
mat activity. The insertion anomaly problem occurs if a 
new activity, such as volleybail (costing $45), 1s added to 
ime l2st of extra-curricular activities. We want to add 
this to the database. However, this is not possible until 
the first student enrolls in volleyball and there is a vaiid 
SID to enter along wath the activity and fee. This is unac- 
ceptable. The only way to add a fact about one data entity 
(an activity) is to first add a fact about another (a 
student). [Ref. 163 p. 287] 


ey 


The deletion anomaly problem can be easily explained 
using Figure 4.2 as well. If the student with SID 100 drops 
out of school and that record containing his activity infor- 
mation is deleted, we lose two important facts. First, that 
student 100 was participating in skiing. This was the 
intent of the deletion and is an acceptable loss. We also 
lose the fact that to participate in skiing it costs 3200. 
This an unacceptable loss resulting from poor database 


design. 











| 
) Student ______Aetivity ! 
| | Sap | AGED Vit y ACTLV iy Fee | | 
| | 100 | skiing | skiing = | 200 | | 
| | 150 {| Swimming | Swimming | 50 
| | 175 Squash | Squash | 50 | | 
| 200 | Swimming | J eoeosegececse/| meme | 
(Ref. 16: p. 287] | 
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Figure 4.2 Modification Anomalies (corrected) 


The design to eliminate the modification anomalies 
in Figure 4.1 is shown in Figure 4.2 . Notice that we have 
provided a means for storing information about students and 
activities independently by creating two separate tables. 
If student 100 is deleted, we still know that skiing costs 
$200. If we want to know how much student 200 has paid for 
his extra-curricular activities, two look-ups are reguired. 
First in the Student table and then in the Activities table. 
Additionally, if vclleyball (fee = $45) is added to the 


activities list, we don't have to wait for a student to 


Sy 


Sarol 1; wie — PUrOonDathon 2S ~entered™ directly into the 
Activities table without considering the student data 


entity. 


Eee Data Duplication 


The problem of data duplication is illustrated in 
Figure 4.3 . The table shown contains information about a 
reservist's Social Security Number and his Reserve JUnit 
(UIC, Long Name, Addzess, City, State, Zip). It is immedi- 
ately cbvious that this design will waste a large amount of 
storage. The same information is stored about the Reserve 
Unit for every member of that unit. One “copy of each 
reserve unit's address is suxficient. Data TauplLed: 1On 
Securs because information about two data entities 


(Reservist and Reserve Unit) is stored in the same table. 
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Figure 4.3 Data Duplication (uncorrected) 


Eliminating data duplication is a relatively easy 
process. The method is very similar to dealing with modifi- 
cation anomalies. Two tables are created so that each data 


entity has one to store its information in. Figure 4.4 
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shows the two tables that are necessary to eliminate data 
duplication. This design has the RUIC field in both tables 
to act as a cross-reference. Eliminating all but one copy 
of the Reserve Unit's address significantly improves the 


performance of the database. 
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Figure 4.4 Data Duplication (corrected) 
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We have identified the major inherent problems in 
database design. There are others that occur infrequently 
and will be discussed as they pertain to the normal forms. 
Fach of the normal forms will now be explained and an 
example from our prototype design will be used to illustrate 


these concepts, where possible. 


5 4 


First normal form is the easiest to satisfy because 
it is the broadest. Een dtlOnmels In L£lrst normal form if 
all occurrences of that record type contain the same number 
of data fields and none of these fields contain the sane 
type of information. These are called repeating groups. The 
data elements dictionary for RTSS had numerous repeating 
groups. This 1s not acceptable in relationai theory. FOr 
example, the data field Secondary Navy Enlisted 
Classification (SNEC) was allowed to repeat in one record for 
up to four occurrences. We eliminated this first normal 
form violation by creating the table snown in Figure 4.5 
Note that the number of data fields is only two and that ail 
records are the same length. Repeating groups are eiini- 
NMated by making a separate record for each SNEC. The proce- 
dure shown in Figure 4.5 was used in allcases where we 
found first normal form violations in the RTSS data elements 


dictionary. 


4. Second and Third Normal Form 


Second and third normal forms are usually discussed 
together. These deal with the relationship between the key 
and nonkey data fields. A key is one or more data fields 
that uniquely identifies a record. A nonkey data field "must 
provide a fact about the key, the whole key, and nothing but 
the key" (Ref. 15: p.- 120}. 

Second normal form is violated when a nonkey data 
field is a fact about only part of a composite key. Figure 


4.6 shows a table that keeps track of the reserve unit and 


reserve billet sequence code(RBSC) relationship. The 
address of the Reserve Unit is also stored. DAtaAsaupilica- 
tion is an obvious problem with this design. Second (and 


third) normal form eliminates this problem. In this partic- 
ular case, the reserve unit's address is a fact about only 


Reserve Unit and not about’ RBSC. Figure 4.7 shows’ the 
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Figure 4.5 First Normal Forn 


design in correct second normal forn. All oz the nonkey 


data fields now describe the whole key and not just a part 
Of wa 


Third normal form is violated when a nonkey data 
field is a fact about another nonkey data fieid. This as 
very Similar to second normal form andis resolved in the 
Same Manner aS Shown in Figure 4.7 When a relation is in 
third normal forn, every data field is either part of the 
key Or provides a single valued fact about exactly the whole 
Key [ Rei osm pon tiene 
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Figure 4.7 Second Normal Form (corrected) 


o-  fOurth amd Fifth Nortel Forms 


Fourth and fifth normal forms have evolved to solve 
those problems involving multivalued facts. Multivalued 
mrcts Correspond to many-to-many and many-to-one relation- 


- ships. An example of these two relationships is shown in 


3) i! 


Figure 4.8 . Part A shows that a student may be enrolled in 
more than one class and each class may have more than one 
student. This a many-to-many relationship. Part B shows 
that a father may have more than one child but that a child 
may only have one father(natural). This is a many-to-one 
relationship. 

There were not many incidences of multivalued facts 
in the Naval Air Reserve prototype design so we will not 
continue with a discussion of fourth and fifth normal forms. 
In designing our prototype, we accounted for the few multi- 


valued facts in the proper manner. 
6. Tradeoffs 


The result of a fully normalized design is a data- 
base free of modification anomalies and data inconsisten- 
cles. One major advantage of full naornalization ae 
minimizing maintenance problems involved with a continuously 
updated database. Fewer, Simpler rules exist for personnei 
who update information in the database when design-related 
errors have been eliminated. The computer operators can 
concentrate their efforts on entering correct data into the 
database. 

There 1s a tradeoff involved with this ‘superior' 
design. A performance penalty may be paid fora fuily 
normalized design. Retrieval can be expensive, since data 
which may have cbkeen retrieveable from one record in an 
unnormalized design may have to be retrieved from several 
records in a normalized forn. The advantages outweigh this 
penalty because most records are smaller and can be accessed 
individually without concern for the physical structure of 
the database. (Ret. 15-eee wizog 

The proper balance between a fuily normalized effec- 
tive design, and a less normalized, but more efficient 


design, is difficult to achieve. The correct balance for 
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Figure 4.8 Multivalued Relationships 
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one organization may be different for another. TALS isi 
function of the way the organization uses the database. If 
retrievals are predominant, a design that contains some 
well-placed data duplication would be a more appropriate 
database design. In the case of the Naval Air Reserve 
DEOL Gr yre, a Small amount of data duplication has been 
allowed. This will improve efficiency of the design without 
permitting any modification anomalies. A later section on 
improving efficiency using ORACLE features will explain how 
greater efficiency was achieved. 

Appendix A, the data elements dictionary, shows the 
physical structure of our design. This design contains all 
of the data entry minimum reguirements discussed in 
COMNAVAITRESFORINST 1510.1 (of 29 August 1984)% with the 
following exceptions: 

a) BSN/CURRENT 

b) BSN/DATE ASSIGNED 

Cc) BSN/PREVIOUS 

d) BSN/7DiSTREBO te) 

e) BSN/TRAINED 

f) NEC/DISTRIBUTED 

gj) NEC/TRAINED 
This design is the first iteration of the prototype design 
and will be tested by the end users. Recommendations for 
Changes will be incorporated into later versions of the 
prototype. 

Througnout the rest of this chapter, we will use 
examples from the prototype to iilustrate a concept. You 
Should refer to Appendix A frequently so that the figures 
are meaningful. 


a ee ES ee ee ee ee eee ee oe 


: *CCMNAVATRESFORINST 1510.1 provides. Pe Le and guidance 
cor the utilization of the Reserve Training upport Systen 
for Air by COMNAVAIRESFOR commands. 
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C. ORACLE DATABASE BANAGEMNENT SYSTEM 
1. Zhe Systen 


Now that the basics of database design theory have 
been explained, we can present the specifics of the Naval 
Air Reserve prototype. The first step in presenting the 
prototype is to introduce the database manag2ment system 
that we chose to implement the design on. Once you are 
familiar with the features of ORACLE, we will discuss how 
they were used to incorporate the important attributes of an 
effective management information system into our design. 

The ORACLE database management system is marketed Dy 
Relational Software, imeOLpOrated, > of Menlo Park, 
Game rornia. The first copy of ORACLE was installed in June 
1979. Relational Software has implemented ORACLE on Digital 
Equipment Corporation's (DEC) PDP 11/23 through 11/70 series 
processors using BSX-11M, IAS, and UNIX operating systems 
and the VAX 11/780 under VMS and UNIX. Stabu li omens 19.0 |, 
they also began offering versions that ran on International 
Business Machines(IBM) Corporation's 360, 370, 4&3xx, and 
303x series processors under VM/CMS and MVS operating 
systems. The company recently announced that all of ORACLE, 
not just a subset, wili be available to run on the IBM PC XT 
and PC AT. 


2- System Features 


ORACLE provides a wide range of features which are 
listed below: 
a) Fully integrated data elements dictionary. 
b) Provisions for use in both distributed and  local/ 


central environments. 


Skelational Software, Inc. has since changed its name to 
CrAacLe, Inc. 


6 7 


c) Provides full support for IBu&'s relational language 
SQL(also called SEQUEL 2, for more details see subsec- 
tion 4). 

d) Fully reentrant code. 

e) Multitask processing. 

£) Interactive applications generator. 

g) Full function report writing fac@lity that “ine 
both text processing and procedural language cptions. 

h) Operates in batch and on-line(interactive) environ- 
nents. 

i) A host language interface and precompiler to allow 
COBOL, FORTRAN, and C applications programs to inter- 
face with SQL and the database. 

j) Data communications support for ail DEC equipment 
mentioned earlier and for IBM 360 and 370 systems. 

k) Security and privacy mechanisms operating at the data- 
base, table, record, field, field value, and key 
levels. 

1) Restart/recovery options which are automatically trig- 
gered when failure is sensed. 

Many of these features were used in our application and will 
be described in more detail in the appropriate sections 
later in this chapter. 


3. System Components 


ORACLE can be divided into three major comyonents: 
the SQL data language, a data elements dictionary, anda 
kernel( see Figure 4.9 ). SQL is an English=like, “Wig 
level language that will be discussed in detail in subsec- 
tion 4. 

The fully integrated data elements dictionary isa 
very powerful tool for us as database designers and for the 
Naval Air Reserve as the eventual end-users. The dictionary 


contains table, row, and column definitions, views of tables 
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[Re£. 173: p.112] 
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Figure 4.9 ORACLE Component Block Diagraal 


and data fields, and information about users and their data 
access privileges [Ref. 17: p. 111]. 

The table, row, and column definitions are assigned 
dynamically when they are created. Any modifications to the 
database are automatically entered without the need for the 
designer to reorganize the database or recompile the 
existing programs (Ref. 173 p. 112). The dictionary also 
keeps track of the views of all tables, who created the 
view, andwho has access to it. A view isa restriction 
placed on a table so that only selected columns and rows are 


r 
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visible to selected individuals. In other words, the data- 
base deSigner can specify what tables a user Can see, and 
within those tables, what columns and rows that user can 
see. This feature aliows information to be hidden fron 
those individuals who should not have access to it. All 
security and control information on data and users are hept 
in the dictionary. 

The third component of ORACLE is the kernel. The 
kernel allccates resources for ORACLE in the same manner 
that the operating system allocates resources for the 
computer systen. The following paragraph, [ Ref. 17: p. 
113], best describes the kernel: 


The kernel automatically reallocates and reuseS space 
from a central storage pool to optimize the physical 
location of related data items within the database. Bete 
addition, the kernel dynamically manages all ORACLE 
buffers, using an LRO (LaSt Record Update) caching algo- 
rithm to maximize reuse of core~-resident information ‘The 
kernel also enables ORACLE to support multiple concur- 
rent t-atch and on-line terminal updates and queries to 
the database. It can overlap I/0 operations up to the 
limit of the hardware configurations. 


4. SQL 


SQL is an English-like language that supports five 
functions: query, data definition, data manipulation, data 
control, and host language coupling. The English-like char- 


acteristics of SQL are ideal for non-procedural queries of 


the database. The user describes what he/she wants uSing 
English terms, such as shown in Figure 4.10, and ORF@rR: 
formulates a procedure to find the desired data. (Ref. 18: 
pe) 362) 


The guery function relies on ‘an operation calied 
Mapping for its success. Using Figure 4,10, the concert of 
Mapping is that a known quantity (RUIC = 29604) is used to 


find a desired quantity (SSN and Last Name) from a relation 
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i ee Seats os = 


SELECT SSN, NAMELAST 
FROM NAME 
WHERE RUIC = 29604; 


ee 


Figure 4. 10 Non-Procedural Language 


ne temic ecrenn-cocae SEP axspanp Steves quia Sona 


or table (NAME). The three basic terms used for queries are 
Peescr, FROM, and WHERE. SELECT is used to declare the 
desired information, FROM gives the relation(s) to be 
searched, and WHERE provides the known fact that must be 
Satisfied by the desired data. Figure 4.11 provides some 
basic examoles of the guery facility. For a more detaiied 
discussion of SQL, consult references 17 and 18. 

The data definition language (DDL) is used to define 
tables, rows, columns, views, indices, and clusters (indices 
and clusters are discussed later in the section on improving 
system performance). The data definition language facility 
is primarily a tool for the database designer. However, 
once the database is installed, the DDL can be used by the 
user to adapt the system to meet the needs of the dynamic 
environment it is supporting. This facility describes the 
data structure that will be used by the other features of 
ORACLE. A data structure must first be defined with DDL 
before it can be accessed by the other SQL facilities. 
Figure 4.12 illustrates how two of the most common terms are 
used. The two examples are self-explanatory since they are 
English-like. The number in parentheses is the maxinun 
humber of spaces that a particular data field can occupy. 
NOT NULL is the SQL method for making a field mandatory. 

The data manipulation language (DML) allows users to 
Change the value of data stored in the database. There are 


three operations that can be performed: insertion, deletion, 
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1. Nested Mapping--Find the SSN and Name of all 
Reservists in the Houston area 


SELECT SSN, NAMELAST 
FROM NAME 
WHERE RUIC IN 
SDs EL UES 
FROM SREOERV UNE 
RHER tei LY = *EOUSt oN; 


2. Count--How many different PNEC's are there at 
RUIC 29604? 


SELECT COUNT (UNIQUE PNEC) 
FROM NAME 
WHERE RUIC = 29604; 


3. Join--a joln_operation must occur when a query 
returns results from more than one table. The 
Jenn operation 1S implicieE. 

hat are the SSN's and RUIC's of ali reservist'’s 
having NEC 0612? (NEC's are stored in two tables= 
NAME Contains the PNEC's and NOBC_SNEC contains 
the SNEC'ts) 


SELECT NAME.SSN, NAME.RUIC 
FROM NAME, NOBC SNEC 

WHERE NAME.SPNEC7= '0612! 

OR NOBC SNEC.SNEC = '0612'; 


Figure 4.11 ORACLE Query Fuaction 


Figure 4. 12 Data Definition Language 
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and update. Peguses 4515  iiilustrates how these are 


accomplished. 
a bea a 
| 1. Insertion | 
PNSERT ENZO SPECLALIST 
| Shion. SON, NAME. RULIC 
FROM NAME, NOBC_SNEC 
| WHERE NAME. PNEC = 0612 | 
OR NOBC_SNEC.SNEC = 0612; | 
| 2- Deletion | 
| DeLee Ob BLL TS ] 
l WHERE AUIC™= 32314; 
| 3. Update | 
| UPDATE NAME | 
SET PAYGRADE = ‘t*05! DOR = 850115 | 
WHERE SSN = 123456789; | 
g | 
a te ee Se Se | 


Figure 4.13 Data Manipalation Language 


An insertion is used to to insert new data intoa 
table or to extract data from one table and place it in 
another. Example 1 in Figure 4.13 illustrates the latter. 
In this case, the SSN and Reserve JIC for any Reservists who 
have a NEC of 0612 are extracted from their current table 
and placed in the SPECIALIST table. The data extracted fron 
the original table now exists in two tables--the original 
table it was extracted from andthe new SPECIALIST table. 
Notice that this example is a query operation linked with an 
insertion. The insertion provides a location for the 
results of the query to be deposited. 

A deletion is used to delete a row or rows froma 
table. Example 2 of Figure 4.13 shows the deletion of all 
rows from MOB_BILLTS where the Active UIC is 32314 (assume 


this active unit was decommissioned). 
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An update is used to change the value of one or more 
data fields in either single or multiple rows. Example 3 of 
Figure 4.13 shows how to record the promotion of the member 
with SSN 123456789 to Commander (paygrade 05) and his Date 
of Rank to 15 January 1985. 

The fourth £UNCtION OL SOL oas data Seomero. The 
data control language(DCL) enables the user to specify who 
will have access to his/her data and to enforce data integ- 
rity constraints. The phrase ‘their data' implies ownership 
by the user. In fact, this 1s the case. The person who 
creates a table, ‘owns' it and has the authority (and 
responsibility) to designate who else can interface with 
that table and its stored data. The following privileges, 
fRef. 19: p. 182], can be granted by the owner of a table: 

a) SELECT--data ah Your ~Table- 

b) INSERT--rows in your table. 

c) UPDATE--columns in your table. 

d) DELETE--rows from your table. 

e) ALTER--the nunmker of columns in your table or the 
Characteristics of a column. 

f) INDEX--create an index on a column of your tabie. 

g) CLUSTER--your table with other tables. 

The owner of the table has the authority to grant or 
revoke any or all of these privileges. The owner can also 
grant privileges to ail users by using the term PUBLIC. 
Additionally, if the owner specifies GRANT OPTION when he 
grants privileges, the recipient of the privilege can grant 
that privilege to  cthers. A example of data control 
language is shown in Figure 4.14. 

The use of the data control facility to enforce data 
integrity is essential to the development of a database 
Maintenance policy. This 1s discussed in detail in the 


section on data integrity. 
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GRANT SELECT, INSERT, UPDATE 
ON NAME 


TO ADAMS 
WITH GRANT OPTION; 


Hi 





Figure 4.14 Data Control Language 


The final function of SQL is the host language 


maeriace. The host language interface allows SQL state- 
ments to be included in FORTRAN, COBOL, and C programs. A 
precompiler (part of the ORACLE package) intercepts these 


statements and converts them into valid statements of the 
host language. The host language interface and precompiler 
may be used with a main menu to make entry into ORACLE'S 


facilities easier and more user-friendly. 


D. DATA SECURITY 


1. Unauthorized Access 


The Naval Air Reserve prototype must have the appro- 
priate security measures built in to minimize the risk of 
unauthorized users viewing, modifying, inserting, On 
deleting data. There must be security provided to protect 
against unauthorized access from both local and remote 
Sites. The remote site considerations involve securing 
communication links and transmission lines in a manner 
appropriate for the information that can be accessed. We 
will not address this aspect of security as it is beyond the 
scope of this thesis. Additionally, we will not address the 
area of physical security of the computer installation. 

Protecting the database and the data are two 


distinct issues we will deal with. The database must be 


Ge 


protected from unauthorized users and the data must be 
logically partitioned so that only those users who have’ 
access to the database and the need to know are authorized 


to see specific data. 
2. Navy ADP Security Program 


OPNAVINST 5239.17A (DON ADP Security Manual) requires 
a combination of hardware, software, and administrative 
procedures to protect data from unauthorized disclosure, 
modification, O© destructor. Adequate protection is also 
required when the system is distributed or allows multiple 
users. RTSS is such a system and ORACLE accommodates this 
reguirement with a lock out feature that will not allowa 
user to access a record that 1s being used by another user. 
This eliminates the problem of two users changing the sane 
data and only the last of two being recorded. With lock 
out, each user sees the current data in turn and knows what 
he is changing. 

This instruction also calls for anwaudit tranieeoe 
cases where the data is of a sensitive nature. As will be 
discussed later, the ORACLE audit trail feature is not 
supported. With this exception, ORACLE can comply with 


these DCN guidelines for ADP security. 


J- 0 Database sacces 


The first barrier for stopping unauthorized access 
is the computer center door. Physically limiting the feorle 
who enter the terminal room can help stop some unauthorized 
accesses. However, if the size of the organization or the 
humber of users is large, this can be a time-consuming, 
expensive, and ineffective method of enforcing access 
linits. 

The most common method of access authorization 


involves using a password scheme. The process of ‘logging 
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on' to the VMS operating system and ORACLE database manage- 
ment is shown in Figure 4.15. The user must type in his 
Mame and then his password next to the appropriate prompts. 
This action places the user in the operating system environ- 
ment. In this case, Winslow has successfully logged on NO, 
the VAX 11/780 computer and the VMS operating system. Note 
that a string of X's appear where the password is typed. 
This is an additional security feature that hides your pass- 
word from anyone looking at your screen. In most cases, the 
password would be invisible, but we show 'xxxxxx' to indi- 


cate a masked password. 


You are connected to VAX/VMNS 11/780. 


ENTER USERNAME: WINSLOW 


ENTER PASSWORD: xXXxxxx 


Welcome to the C.S. Department's VMS 3.7 systen. 


GB eee CO as eee ge OE gees co teal me ecg COR GE GE RT ee Ge ey I pe ey es Aa Ges eee Co 





[ 
| 
Current Software Versions: VMS 3.7 BOR OR A Nees. 2 
PASCAL 2.5 ORACLE 4.90 
| ORACLE 
| $ FI 
} SEAS OEp.ge coeyesoys on, 90242282- 488). 0982 85 
CommceuinNgneco- ORACLE V4.0.12 —sProduction 
ENTER USERNAME: HINSLOW 
ENTER PASSWORDS XXxXxXXX 
| UFI>exit 
| Logged off from ORACLE. | 
| | 
ee ee eS ee SS eee ee eee J 
Figure 4.15 User Authorization{Log on) Procedures 
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Winslow now has access to all application programs 


and facilities tanat are available to the user under the VMS 


operating system. He chose ORACLE in our example ana typed 
NORACLE"™ next to themes Seconpt. The "$" appears aS a 


prompt at all times when you are in the MS environment. 
Winslow then types "UFI" (for User Friendly Interface) to 
enter that particudan ss tacie eye UFI is the primary means 
that a database designer or user talks to ORACLE using the 
Data Definition, Data Manipulation, and Data Control 
languages. 

ORACLE requires the user to log on again so that it 
can check its own list of access privileges for proper 
aAUthorrzation- This is a two-tiered process. First, “tite 
username/password combination is checked for access to the 
database itself. An authorization failure will result in 
the user being asked to log on again (in case the user typed 
the information incorrectly). ORACLE will tolerate two such 
failures and will exit to V4¥S if a third occurs. ioe 
successful, the message shown in Figure 4.15 will appear, 
followed by the "UFI>" prompt. We show how to enter the UFI 
facility, but the log on procedure for all of the ORACLE 


facilities is the same. 


uy Data Access 


The second tier of user authorization cross- 
references the username against a table that records who 
Owns what tadles and who has been granted privileges on 
those tables. This is an extremely powerful feature of 
ORACLE that provides a high level of Security on the data 
resident in the database. 

This security mechanism operates at the table, 
recond, data field, and data fielguyva vies lev It works 
using two different methods; through the control of privi- 


leyes granted on a table and through the creation of views 
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that logically restrict the data that a user can see. we 
will discuss each of these methods in the following para- 
graphs, using examples from the prototype. 

The use of privileges to control access was 
mentioned briefly in an earlier section. To review, the 
following privileges can be granted (or revoked) by the 
Owner of a table: 

SO LECT 
b) INSERT 
c) UPDATE 
ae DELETE 
PAL TER 

Eee N DEX 

g) CLUSTER 

When a user attempts to manipulate the data ina 
table, ORACLE will first verify that the operation kas been 
authorized by the owner of the table. Tmeemac part rcular 
privilege has not been granted, ORACLE will not allow the 
operation and generate an error message saying that’ the 
table does not exist. In other words, if an unauthorized 
operation is attempted py a user, ORACLE wili mask the table 
as if it does not exist. The tabie is blocked by the systen 
from unauthorized access. 

It is the responsibility of the owner of the table 
to carefully grant privileges to selected users. Bach 
users’ needs must be analyzed on a case basis. ayslelel  ye\ea iste 
iege granted must be justified before it is granted. 
Granting of privileges must be closely tied to jok reguire- 
ments. Figure 4.16 shows three levels of privilege options. 

The upper level is for the database administrator. 


In the prototype, Winslow serves as the DBA® and has all 





Sinwactuaiaty the DBA has more privileges, than_those 
shown. This prototy e was designed on ORACLE installed on 
Peemwoouplmecm octence VAX 1177/80 ana a computer science staff 
member retained full DBA privileges. 
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privileges on all tables and the authority to grant those 
privileges to others. 

The middle level shows the set-up for middle level 
Managers, such as a department head. Note that Seeger 
(acting as Operations department head) has less privileges 
than the upper level. Additionaiiy, ne has only limited 
authority to grant privileges to others. 

The lower level of privilege options is for those 
individuals who perform record input and update. These 
individuals have update and insert must receive their privi- 
leges from an authorized user in the upper two tiers of the 
privilege scheme. This ensures privileges are controlled 
at a high level and that managers know who have access to 
the data in the datarase. 

Note that only the upper level has the ielete privi- 
lege. This privileye is reserved for this level because we 
are not allowing any deletions in our database prototype. 
If a record is to be deleted, the input operator marks the 
record for deletion and the person holding DBA privileges 
Will periodically move the deleted records toa history 
file. 

The security mechanism for records, data fields, and 
data field values is the view. A view is a logical parti- 
tioning of data so that the user only sees a subset of the 
table (or tables). A view is like a window in a building. 
It allows people to look at only a certain portion of what's 
inside. When a view is created it allows specified people 
to see portions of the database. 

Figure 4.17 showS how a view was created for the 
prototype. This view allows the Operations department head 
to see only the Operations department subset of the table 
"NAME." This view requires gathering information from two 
tables. First, all SSN's from the RUIC_BILLETS table with a 
Department of 'OPS' are chosen. Then, all the data fields 
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Figure 4.17 Alternative View of Data 


listed in the two SELECT lines are gathered for the individ- 
uals whose SSN's were collected from &UIC_BILLETS. This 
information is the subset called the OPS view. The view 
does not physically contain any data, so creating a view 
does not mean storing the same data twice. This would be 
very inefficient and present some difficult data maintenance 
probiems.?” 

The procedure in Figure 4.17 shouid be repeated for 
each department. The view is created with the department 
head as tke owner and controller of all privileges. The 
department head can look at the entire NAME table (by using 
the SELECT option shown in Figure 4.16) but can only manipu- 
late the data in the OPS view of NAME. This arrangement 
allows the command to maintain control of the entire data- 
base and gives the department head freedom to manipulate his 
Subset of the database. 

Now that we aave described how this prototype 
protects the data from unauthorized access on several 
levels, we must briefiy discuss how an unauthorized access 


attempt can be detected. The latest version of ORACLE has a 


7Storing the data twice about the same person would nean 
that if the data was chanced, it would have to be updated in 
two places. The overhead required to do this would render 
viewS useless. This does not occur. 
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meature called AUDIT TRAIL that 1s supposed to record 


certain events. The designer was to specify what events, 
such aS unauthorized access attempts, would trigger tne 
eiidet trail. Bieeaidlteeteatmewoulds then take a picture of 


what happened and who attempted it. 

After a futile attempt to implement this feature, we 
contacted ORACLE, INC. and were told that the feature did 
not work and was no longer supported. This 1s a weakness of 
some Significance, butenot | fata This shortcoming was 
partially offset by procedures designed to protect the 


database. 


Ee DATA INTEGRITY 


Data integrity involves the correctness of data. The 
purpose of enforcing data integrity rules is to ensure that 
correct data is entered into the database and that it 
remains correct while there. The technigues to enforce data 
integrity are transaction validation, format checks, and 
reasonableness checks. [Ref. 20: p. 218]. We will discuss 
what each is and how they were implemented in our prototype 
using ORACLE. 


ieee transaction Validation 


SS SS Se SS SSS SS SSS SS aS SS SS Se SS a SS SS 


A transaction validation is concerned with ensuring 
that an input or modification is authorized. This was 
discussed in great detail in the Data Security section. 
ORACLE enforces this with the privilege facility. Only 
transactions authorized by the owner of the table are 
allowed (refer to Figure 4.16). Proper security is the 


first step toward sound data integrity. 
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2. Format Checks 


Format checks ensure that the data to be entered 
coniorms to certain pre-defined criteria describing the 
physical structure of each data iten. ORACLE accomplishes 
this through its active Data Elements Dictionary. 

The data elements dictionary for our prototype is 
contained at Appendix A. It lists the the data field name, 
its type (number, character, or date), its length (this is 
the maximum length allowed), and whether the field is manda- 
LOEY.- Nuil means the field can be blank; Not Null means it 
must be filled. A field may te of type ‘character' even if 
it contains only numerics. The choice 1s based upon whether 
arithmetic will be performed on the data field. Arithmetic 
Operations are not permitted on character type fields. 
Ret. Z2iswpeeo. 

The data elements dictionary will perform the 
following format checks on all data input transactions 
automatically: 

a) Length checks--ensure data does not exceed the maxinun 
prescribed number of characters. 

Dy Charactep—t pe Cchecks--ensure data is of the 
prescribed type. 

ii aadat on to the data elements dictionary 
enforcing prescribed format, our prototype has a series of 
input programs that contain additional format checks. These 
programs, created with the Interactive Applications 
Generator, allows the input operator to execute a "screen" 
that aids in the input process. Appendices B through F 
contain a picture of the screens and the interactive 
programs that create then. These input screens enforce the 


criteria that there must a fixed number of characters.3 


Sa SS Sms a eS ee eee ee ee 


.,,°FOr example, RUIC will always contain five numbers, SSN 
Wwili always contain nine numbers, and STATE will always 
contain two characters. 


ues 


ORACLE does not have the ability to verify that data 
contains a prescribed pattern. For example, EBSC has a 
pattern of four digits and then a letter. We can not check 
that this pattern is adhered ie) fae L éjoithe time. 
Consequently, RBSC is specified as character, with a maximum 


of five spaces in the data elements dictionary. 


The final check is a reasonableness check. After 
the transaction 1s confirmed as valid and the format is 
correct, we must check to see if tae value of the input data 
falls within reasonableness constraints. For example, for a 
two-day Weekend Training (WET), we do not want the number of 
driiis entered to be greater than four. Oracle supports the 
following reasonableness checks: 

1. Field Constraints--Each of these three are accon- 
plished in ORACLE with the Interactive Applications 
Generator mentioned earlier. 

a) Range--checks the upper and lower limits of the 
data entry to ensure they are with in acceptable 
bounds. 

b) Completeness--used to ensure that mandatory fields 
have been assigned values and that fields witha 
set number of characters have been completely 
fede | Geet. 1. 

c) Code--used to verify that the contents of a data 
field contain a code that is authorized ina list 
of current codes. 

Pease tneerrecord/intrarecord--Each of these are also 
accomplished with the Interactive Applications 
Generator. 

a) Completeness checks--used to ensure that certain 
fields are filled inas a result of entries into 
other data fields. This occurs within a record 


and between records. 


Fis 


b) Consistency checks--used to ensure that values in 
certain data fields arevalid in relation to 
entries in cther data fields. This is also done 


within one record or between records. 


F. IMPROVING SYSTEM PERFORMANCE 


A relational database system can be inefficient when 
data from very large tables or from several tables is 
retrieved. If there 15 no plan £or storing Drelated dacw 
each search through the database must look at every record. 
In designing our prototype, we developed a plan that limits 
the number of records that are viewed before the correct one 
is “folnaeg This 1s done in ORACLE with indexing and 


clustering. 


1. Indexing 


SS ee ee Se 


Indexing is used to guickly locate the pages® of the 
database that contain specific records of a table. The 
ORACLE index is the same as the index in the back of a text- 
book. It provides ameans of finding subjects without 
looking page by page through the book. The index in a book 
is organized in alphabetical order and allows you to find 
all incidences of the desired subject. 


The indeXing system of ORACLE uses thiS same prin- 


Ciple. It uses its indexes to locate pages on disk that 
contain the desired records. This 1S an excellent way to 
Shorten the time it takes to execute a query. The index 


eliminates the need to search the entire database to locate 


the desired record; nly the page where the record resides 
must be searched. 


.?Database pages are physical areas on, disk storage 
devices that hoid’ the data in the database like paper pagés 
hold the information in a book. —[ReES Mier 1974 
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Indexing can also .bée used to ensure that a column 
Within a table has a unigue value. In other words, a data 
elenent may only have a specific value assigned to it once 
in the table. The primary use of this feature in our proto- 
type is with the data element 'SSN'. We created a unique 
index so that a person's SSN will only be listed once. This 
eliminates the possibility of a member's record lLeing 
entered more than once. If this were to occur, the data in 
each record would be suspect. Figure 4.18 is an example of 
how we created a ‘UNIQUE' index for SSN on the NAME table. 
Appendix D contains the list of indices used in the 


prototype. 


| REATE UNIQUE INDEX SSN K 
E (SSN) ; 
| 


Au 5 


Figure 4.18 Indexing 


Creating an in index improves performance but also 
increases the amount of data stored in primary memory. 
Additionally, if there are excessive indexes, each time a 
record is added to a table that is indexed, ORACLE updates 
each. The more indexes there are, the more work ORACLE has 
to do to keep them current. This will slow down the entire 
system. [Ref. 19: p. 201] 


2. Clustering 


Clustering of data together in the same physical 
space 1s away of guaranteeing that two tables that are 
often joined together are also stored together. Clustering 


is totally transparent to all queries against the data. 
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This is a way of shortening the time required tow jorn a 
data of two tables when responding to a user-generated 
query. [Ref. 22: p. 25] 

Figure 4.19 shows how we created a cluster to store 
the two tables together where 'RUIC' for each is the same. 
The cluster is created first, then each table is added to 


it. Notice that it is a-three step process. 


a ea ec 
1. CREATE CLUSTEnN er Uren. viCc 
(RUIC NUMBER) ; 
Cluster Created. * 
oe ALTER ChUSEER RUwS 


AU 
ADD TABLE RESERVONI 
WHERE RESERVUNIT.RUIC 


| 
| 
| 
Ic 

ly 

= RUZC UAULC. RUme, 
| Cluster Altered.* 
] Se ALTER CLUSTER SaUre sore 
ADD TABLE “RUCrBtr os 
WHERE RULC Biel oen ce 
| 
| 
| 
Lo 


Cluster Altered.* 


= RUIC_AUIC. RUIC; 


* indicates respense from ORACLE 


| Ce ee eS) faites Godin chet SS et ee i Ge ay es ee 


Figure 4.19 Clustering 


Ali records from these two tabies wnaere the ‘'RUIC' 
is the same will be stored together so that retrieval will 
be faster. These two tables were clustered because the 
queries that will be routinely generated will involve data 
aLout the RUIC that is contained in both tables. A cluster 
is more efficient than an index in this case because only 
one Search must be accomplished to find the data in two 
tables. An index would only locate the page that the 
records are on in two different tables and then each would 


have to be searched. 
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G. RECOVERY 


There is a degree of risk involved with storing infornma- 
stom about an Organization in a computer. Computers stop 
unexpectedly, disk heads crash, operators drop disks, 
programs have bugs, people input incorrect data, and proce- 
dures are ignored [Ref. 16: pe. 415]. These occurrences 
(called media failures) can not be allowed to stop or slow 
down the organization. The data must be reconstructed to 
its original state. The most common way to ensure that the 
database can be reconstructed when some catastrophic event 


occurs is a recovery scheme. 


1. After Image Journal 


The scheme ORACLE uses is roll forward recovery. 
ORACLE uses an AFTER IMAGE JOURNAL to implement this roll 
forward scheme. Recovery is made possible by keeping a 
separate parallel journal of each transaction written to the 
database. A physical record of all changes to the database 
is produced and this can be used to reconstruct from the 
point where the loss occurs. After Image Journaling is 
completely transparent to the user. [Ref. 22: p. 26] 

The procedure is as follows: 

1. ORACLE records each event that modifies the database 
ane places Ptyinto a file. 

2. When the journal grows to a certain size or after a 
specified period of time, the files are copied from 
disk to tape. 

3. Each file is given a seguential number to estaklish 
the correct order of each occurrence. 

4. When a media failure occurs, the last copy of the 
database known to be good is retrieved. Pieris iEs t 
After Image Journal that was created after this good 


copy of the database is then applied. All After 


83 


Image Journals that were created after this first one 
are then applied in order until the database is 
completely reccnstructed. 

An effective recovery scheme using proven software 
and rehearsed procedures is essential to the operation of an 
organization that maintains its files on a computer systen. 
The roll forward recovery technicgue that 1s implemented in 
ORACLE is an effective method. The After Image Journals 
that are created provide a fairly low-risk means of ensuring 
that database integrity can be maintained, even in the event 
of media failure. The key to effective recovery is in the 
procedures established by the computer center management. 
These procedures must be practiced prior to a nedia failure 


so that when one does occur, its impact is minimal. 


H. REPORT WRITING 


A modern database management system must have the facil- 
ities to process reports for the organization. It must be 
able to deal with straight text anda combination of text 
and datarase query results. This feature can tcelieve an 
organization Of )Muchyor Yikes sola, outdated programs that 
extract data from many sources and presents them in report 
zrormat. Because the data is consolidated in one database, 
these reforts are usually easier to write and, more impor- 
tantly, easier to maintain. 

ORACLE has a facility for text formattiny and report 
writing that is capable of database retrieval. There is an 
interactive feature that aliows inputting a value for a 
variable before the data is retrieved and formatted. This 
1s particularly useful when a report is being prepared for a 
Reserve Unit and the computer operator supplies the RUIC 
before the data is retrieved. It can also be used fora 


document for an individual reservist by supplying their SSN. 
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Ye attempted to develop several reports that were repre- 
sentative of those in existence for the Reserves. In 
general, we found the report writer cumbersome and difficult 
ceewOrk with. For a series of reports to be produced, the 
computer operator must issue several commands or write a 
program in either COBOL, FORTRAN , Or 1G; Use of these 
languages is what we are trying to eliminate; thas as 4 
negative factor in many of the fourth generation languages 
today. 

In each report we attempted, we discovered an apparent 
"bug" in the ORACLE software. This problem has been encoun- 
tered by all those we know who have tried the report writing 
eae lity. This is not to say the data can not be accessed, 
for the query facility in the User Friendly Interface can 
accommodate short, simple reports. But the problem isa 
major okstacle in ORACLE'S consideration as an integrated 


database management system for the Naval Reserve. 


I. ORACLE'S GRADE 


ORACLE is a relational database management system that 
provides a fairiy easy means of developing a database proto- 
type. Zts active data elements dictionary is an excellent 
feature that aided us as designers and gave us a large 
degree ort flexibility when changes were reyuired. 

ORACLE has the necessary security, data integrity, and 
performance enhancement features to satisfy this application 
for the Naval Reserve. In general, the features listed on 
pages 59 and 60 make this system a desireable product. 
However, the problems noted with the report writer feature 
are critical in the choice of a software systen. ee one 
support for this feature 1S improved and the problems are 
corrected, then this product would be a good choice for the 


Naval Reserve. A caution--this thesis did not set out to 
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evaluate the software market for database systems. In 
critiquing ORACLE, we are not comparing it to other systems 
for performance or price. That analysis must be completed 


before an informed selection can be made.. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 


After eight years of planning and implementation 
efforts, RTSS is not getting the job done. The outlook for 
a new contractor to effect a major breakthrough on a systen 
that uses old hardware and ancient (by today's standards) 
software 1s grin. The Navy tried to upgrade just the 
training software and failed. Substantial progress towards 
the goal of an integrated training and mobilization database 
for the Reserves cannot occur using the present technology. 

At CNAVRES, manual intervention is still a must in order 
to obtain training and mobilization data. R@sS _ (Air) 
remains linked to a fourteen year old ATSS system whose 
software still cannot transfer records from one site to 
another. Software updates are late, insufficient, or non- 
existent. The functional sponsorship for the entire system 
lies elsewhere. RTSS (TM) 1s dependent on an IMAPMIS AIS 
that 1s in need of extensive revision, again by a functional 
sponsorship outside the Reserves.1° The RTSS systems are 
redundant and poorly designed. Progress since inception of 
the systems has been glacial. 

The skeletal staff at Code 46 is determined but help- 
less. Overwhelmed with milestone management, they lacx the 
time and budgetary control for exfective AIS strategic plan- 
nrg. They recognize the need for redesign of the software 
away from the current system and applications software, but 


have not yet been successful in converting those needs into 
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10Code 45 CHI ee MO LANG HES) was extremely frus- 
trated with the state of ADP Sie for his needs. Fis 
RTSS/IMAPMIS experience has served to make him adamant that 
any future RTSS must not be associated with or dependent on 
any otner system. [ Ref. J 
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POM items. Money for ADP has been cut back in past years. 
Virtually all ADP funds are being funnelled into maintaining 
the current inept system. Innovation has no priority on the 
mobilization battlefield. . 

Code 461 1s presently trying to find the money to 
convert the file structure of RTSS from the RSTS/E operating 
system to the VMS operating systen. This in-house, i.e. 
non-NAVAIR, effort will take considerable contractor 
support. A PDP 11745 stands ready at New Orleans for 
research and support in the conversion efforts. 

The DDN problem must also be resolved. Conversion of 
the current system to allow terminal to host processing on 
the DDN is still an issue. Estimates for initial protocol 
conversion for the RSTS/E operating system by various 
contractors have ranged from $150,000 to $300,000, with 
approximately $50,009 reyuired annually for maintenance and 
support. Yet wide area network interface products already 
exist for VAX(VMS) machines, and the progress in local area 
networks for microcomputers such as 2Z2-150s yields a new 
product monthly. The major studies cited previously in this 
document have looked at both Navy and Reserve AIS prcblems 
and determined that cumbersome redesigning efforts on obso- 
lete systems are a waste of valuable resources. 
off-the-shelf technology is available today. 

All of these issues and questions can best be resolved 
by those trained and experienced in dealing with then. The 
Information Age 1s a reality whose workings are fast 
becoming the modus operandi for the Navy's business. The 
fields of networking, office automation, database manage- 
ment, and requirements analysis are full of pitfalls in 
which to lose valuable time and money. More and more 
dollars in the ADP world are going towards the labor costs 
of software maintenance, and less dollars for hardware that 


1s becoming cheaper and more effective. Outside contractor 
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sourcing for soitware services has become a way of life for 
the Navy. Yet, for the cost of some additional ACDUTRA 
drills, the Reserves have many of those reSources readily 
available. There are many individuals who are not oaly 
skilled in the intricacies of AIS management, but well 
versed in the unigue needs of the Reserves. The Information 
Systems Support Unit must be implemented if the Reserves are 
to efficiently and effectively plan for the automation of 
training and mobilization. 

Software prototyping using off-the-shelf fourth genera- 
tion query and database technology is fast becoming an 
acceptable alternative to the lengthy and complex method- 
ology traditionally used. Certainly, no system can hope to 
be free from potential error. Management must still 
control, coordinate, and plan. Users must work closely with 
developers until they're skilled enough to go it alone. The 
primary advantage of prototyping is the ability to get 
results quickly, and then to continually change as proklems 
arise or, more likely, needs change. Thais cycle of feedback 
and change is not available using the software and reguire- 


ments analysis technigues of the past. 


Be. RECOMMENDATIONS 


Several alternatives face the Reserves as they attempt 
to fix some rather extensive AIS problems: 

1. The Reserves could simply continue on tne ovpresent 
course of letting the Active Navy design and impie- 
ment a follow-on system, as may be the case with the 
present Source Data System plans and efforts. The 
Reserves will have to live with whatever that system 
becomes, and it is only now in the planning stages 
for including Keserve reguirements. However, there 


is a notable history of the Reserves taking a back 
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Seat when it comes to sharing common resources; the 
hand-me-down nature of support received from ATSS 
facilities by sharing 9755S sites 1S painfully appa 
cable. The delay before SDS implementation also 
means another five years (approximately) of chaos in 
handling tralimingvandsnebt yzaion data. 

A major effort could be made to redesign the current 
applications software and file structure to run on 
the more efficient and DDN compatible VAX(VMS) hard- 
ware. In terms of dollars and results, this would 
probably be the cheapest way to ‘'fix' the present 
disarray of applications. It would leave just that: 
a ‘fixed' antiguated system of applications with a 
database system that is really a file management 
system and has little or no room for expansion or 
major changes. 

Re-designing with both new hardware and software is a 
third option which is not overwhelming when manage- 
ment acknowledges that they still must do things 
manually. This option brings to the Reserves the 
functional sponsorship of a system of their own. 
Design from the beginning can best serve their own 
unigue needs, both present and future. Field pilame 
hing teams, under the guidance of an ISSU could 
gather and forward a set of initial requirements BRO)IC 
a prototype. The basic reyuirements of DDN, 
VAX (VMS), and (large) microcomputer compatibility can 
be met by several products on the market today. A 
benchmark or standard could be developed by the ISSU 
for a competitive runoff of the eligible fourth 
generation languages. The ISSU. could then picka 
candidate to buy for their prototyping tool, and the 


Reserves would be on their way to the 1980's. 


90 


We are naturally biased in the selection, of the third alter- 
native as our own recommendation. OuEnectiOuns “at proOto— 
typing are only the first iteration and much remains to be 
done. We were disappointed with the lack of support we 
found in the report writing facility of the ORACLE software 
package, but were impressed with the ease of prototyping 
using a relational software package. The next step in this 
effort should be to develop report writing once the bugs are 
fixed. Additionally, experimentation with a nediunm-sized 
database to evaluate the efficiency of the system is neces- 
sary. 

The ISSU and prototyping wiil goa long way towards 
bringing the Reserve manager of today some meaningful AIS 
leadership and technclogy. The recent upgrading of OP-945 
(Information Systems Division) to a flag billet, and the use 
of new software productivity tools at NMPC-4 are indications 
that the Navy means business in its 'Battle of the Byte’. 
we strongly urge the Reserves to take note, take heart, and 


move toward a sounder and stronger AIS future. 
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APPENDIX B 
IWTERACTIVE APPLICATIONS GENERATOR OUTPUT 


eee - — fReOERVE UNIT INF@RMATION = = = == - 


RESERVE UNIT LONG NAME Roun vb Oe 
XXXXXXXXXXXXXXXKXXXXXXXXX XXXXX 
Slag. COMMERCIAL PHONE NO. 
XXXXXXXXXXXXXXXXXX XXKXKXXXXXK XX XXX XXXXX 
ey Y ene. 4 oe, AUTOVON PHONE NO. 
XXXXXXXXXXXXXXX XX XXXXX XXXXX XX 

RESERVE CENTER UIC 

XXXXX 

Beravi UNIT LONG NAME SGT Ey ULC 
XXXXXKXXXXXXXXX XXX XX XXX XXXXX 
Baar NODES REPLACE PAGE 17 COUNT. HO 


o> 


Soc. “SeC. 
XXX NXKRXKXX 


XXXX XXX XX 


XXXXXKXXXX 


XXX XXXXXX 


XXXXXXXXX 


Char Mode: 


—- ACDUTRA INFORMA LIONS 


No. Type 
Xx 


Xx 


Replace 


Days 
XX 
ro 
xXx 


XX 


XX 


Page 1 


Date 
XX XXXX 


XXXXXX 


XX XXTX 


XXXXXX 


XX XXX X 


96 


AUIC 
XXXXX 


XXXXX 


XXXXX 


XXX XX 


XAXXX 


COUN E ? 


0 


we eo a ete N TT BILLET STRUCTORE - - -7-r-- 


Reserve JIC Rape © Crt ins Description 
XXXXX XXXXX x FE POCOCOCOCOOO SOOO OOOOSS 
Bose O 
11171 
BOG... 0CC. NOs NOBC /PNEC 
111117117 11171 
Intended Rank/Rate Actual Rank/Rate 
XXXXX Xx XXX 
CHAR MODE: REPLACE PAGE 1 COM a: 1 


o7 


PERSONAL INFORMATION = =) ee oe 


SOG. SEC.) NO.) eee xX XK 

First Nane MI Last Name Rank/Rate Status 
PO OEOOOOSS: EE DONO OE CO OOO 4 SOR CK x 
Street Home Phone 

OOOO OC OSOOO COO COOSCOCE OO XXXXXXXXXX 

City ST ZIP BuSiness Phone 
XXX X XM RRM EX XX. “aoe XXXXKNXX Ge xX 
Reserve UIC Leawnen go LC 
XXXXX x xe xX 

CHAR MODE: REPLACE PAGE 1 COUNT 2a 

SOC. SEC. NO. xx k xe 

Birth Date Sex Race 

poo a X ve 

PEBD DEP CODE Clearance 

XX KX X XX PO D'S © 4 

Pay Grade Date of Rank EOS 

XX XXXXXX pee a & ee € 
Precedence No. MOD EXRAA 

TOG & OO ooo < OOo OO 

Lineal No. NOBC/PNEC 
KX X RX KX XXX XX 
CCer Subspecialty 
XeXXX X XXXX 

CHA MODE: REPLACS PAGE 2 COUR: 


1 


fuak MODE: 


sOC. SEC. 
XX XXXXXXX 


XX XXXXXKX 


XX XXXXKX XX 


XXX XXKXX X 


XX XXKXKKXXX 


Dio Leon ORNA Uh ON = 


NO. 


SEN GE 9, 
X 


x 


x 


REPLACE PAGE 1 


a 


NUUBER 
XX 


XX 


XX 


XX 


DATE 
XXXXXX 


XX XXXX 


XXXXXX 


XXXXXX 


ZXX XXX 


COUNT: 


0 


APPENDIX C 
PERSONAL INFORMATION SCREEN 


- #84 THIS PROGRAM IS THE INTERACTIVE APPLICATIONS 

2 #&kaok GFNERATOR CODE THAT IS COMPILED TO DEVELOP THE 
. kaka PERSONAL SCREEN. IT HAS A FILE TYPE OF .INP - 
2 ska TOE COMPILED CODE HAS A FILE TYPE OF .FRM. 


aE eee Title : 
PERSONAL INFORMATION 
SORACLE workspace size ; 


sBlock name / Description : 

PERSNAME 

*Table name : 

NAME | 

soles for uniqueness before inserting Y/N : 
Ey tie how many records : 

-Pield hame : 

SSN 


sType of field : 

NOABER 

sLength of field / Display length / Query length : 
os this field in the base table Y/N : 

sIs this field part of the primary key Y/N : 
;sField tc copy primary key fron : 

*>Default value : 

“EE Ghe : 

sLine : 

“COM My = 


35 


re Oil Sites 

Soc. ec. No. ; 

;sDisplay prompt above field Y/N : 

n 

;Allow fieid to be entered Y/N : 

SOL> 

sis fieid fixed-length 172. 

Y , 

;Auto jump to next field Y/N : 

y : 

;Cconvert field to upper case Y/JN : 

n 

;sHelp message : ; ; é 
nter Member's Social Security Number This field is mandatomy 
*Lowest value : 2 


sHighest value : 


100 


net” name 
T aA Of field 
bake 


meen th of field / Display length / Query length ; 
sis this field in the base table Y/N ;: 
os this field part of the primary key Y/N : 


sDefault value : 
4 5 

‘Line >: 
7 
scolLumn 


10 


mecOmpt 

First_ Name 

;Display prompt above field Y/N 
7 ow field to be entered Y/N : 
e. field to be urdated Y/N 
tsoL> 

fiscetield mandatory Y/N ;: 
ieenrield fixed length Y/N : 


sAuto jump to next field Y/N : 


sConvert field to upper case Y/N 


a ah<d ai are 


sHeLLE message ; 
Enter Member's "First Name - This 
sLowest value : 


;Highest value ;: 


*-Field name : 
NAMEMT 


bath 


- Boe freid < 


field is mandatory! 


sLength of field / Display length / Query length :; 


eo this field in the pase table 


Me Noes 


Meomthis field part of the primary key Y/N : 


;Default value : 

coe = 

A : 

rscolumn : 

;Prompt : 

sDisplay prompt above field Y/N 
ee field to be entered Y/N : 


ON field to be u;dated Y/N 3; 


101 


SOL? 

;Is field mandatory Y/N ; 

its field fixed length Y7 ime 

paleo jump to next field Y/N ; 
sConvert field to upper case Y/N : 


Y 


sHelp message 

nter Member's Waddle Initial-Leave blank if unknown or NMN 

sLowest value ; 

s;Highest value ; 

;Field name : 

NAMELAST 

i e of field ; 

irene of field / Display length / Query length :; 

;is this field in the base table Y/N : 

ie this field part of the primary key Y/N : 

;Default value : 

jee : 

sLine ; 

7 

;CoLumn : 

26 
rom 

ae fame 

;Display prompt above field Y/N : 

a. field to be entered Y/N : 

Ap cLiers field to be updated Y/N : 

s0L> 

sis field mandatory Y/N : 

Ae field fixed length Y/N : 

n 

;Auto jump to next field Y/N : 

eign oe field to upper case Y/N ;: 

eciee message : 

Enter Member's Last Name - This Field is Mandatory! 

sLowest value : 


;Highest value : 


eld 
aaae OR TS ATE 
ae Ot £1 Clam 
CHA 


ESN ehh of field / Display length / Query length : 
ie this field in the base table Y/N : 

oe this field part of the primary key Y/N : 
sDefault value : 


102 


“a o° 
seine : 
“Column : 


50 


acompt : 

Rank/Rate : 

;sDisplay prompt above field Y/N : 
now field to be entered Y/N : 
eal ow field to be updated Y/N : 
‘soL> 

;is field mandatory Y/N 

oe field fixed length Y/N : 

n 

sAuto jump to next field Y/N: 
Convert field to upper case Y/N ;: 
iHelp message :; 

Enter Member's Rank or Rate- LCDR, CAPT, ABHCS, BM2, etc. 
;Lowest value ;: 

;sHighest value : 

-Field name : 


RCDSFIAG _ 
maype of field ;: 


os of field / Display length / Query length : 
sis this field in the base table Y/N : 

mes this field part of the primary key Y/N ; 

fae cust value ; 

co : 

sane 5 
pao, ban ; 
ffacas 

sDisplay prompt above field Y/N : 
sAllow field to be entered Y/N : 
Allow field to be updated Y/N : 
720 L> 

;is field mandatory Y/N : 

sas field fixed length Y/N : 

ent jump to next field Y/N 
sConvert field to upper case Y/N : 


;sHelp message 


* 


A- Active, D- Awaiting Deletion 


10 3 


Lowest value ; 

sHighest value ; 

-Field name : 

SIREE tae 

# e O@ f1elde: 

gress of field / Display lengta / Query length :; 
-Is this field in the base table Y/N ;: 

sIs this £1¢eld part of the premary cece) 
sDefault value : 

aie te : 

: pines 

10 

‘Column -: 

10 

sPrOMeEL 

Stree 

;sDisplay prompt above field Y/N : 

eens field to be entered Y/N 

tallow field to be updated Y/N : 

{SQL> 

;is field mandatory Y/N : 

its field fixed length Y/N : 

pee jump to next field Y/N : 

Se field to upper case Y/N : 

sHelp message : ; 

Enter Member's Street Address- This Field is Mandatory! 
sLowest value : 

sEighest value 

es hame ; 

sType of field : 

kk 

rage of field / Display length / Query length 
pt this fieid in the base table Y/N : 

ee this field part of the primary key Y/N : 
;Default value ; 

SEAGIG : 

Lies: 

13 

-Column ;: 

10 
SPEOmpr s 

City 

;Display prompt above field Y/N : 
ot litres field to be entered Y/N : 


10 4 


ve 

a ° field to be updated Y/N : 

7) L> 

sIs field mandatory Y/N : 

iS field fixed length Y/N : 

peu ° jump to next field Y/N 

pee ert field to upper case Y/N : 

*Help message ; ; ; 

Enter Member's Citvamunis field 1S fandatory! 
;Lowest value : 

;Highest value : 

sField name : 

: f field 

: eeort field ; 
éik o 

sLength of field / Display lengtao / Query length : 
os: this field in the base table Y/N : 

sis this field part of the primary key Y/N : 
sDefault value : 

mg ¢ : 

Srane : 

43 

feolumn : 
30 
et : 

sDisplay prompt above field Y/N: 
a" field to be entered Y/N : 
sAllow field to be updated Y/N : 
yoOL> 
sis field mandatory Y/N : 
Is field fixed length Y/N : 


eo jump to next field Y/N : 


x<ee i<ye 


pageert field to upper case Y/N : 

sHelp message 

fnter Member's State- This field is mandatory! 
;Lowest value ;: 

;Highest value ;: 

*Field name : 

ZIP 

PRS of field : 

NUMBER 

yen t of field / Display length / Query length : 
oe this field in the base table Y/N : 


105 


ee this field part of the praia Keyes 
sDefault value ; 

a) ; 

‘lane 

12 

sColLumn=: 

nae: 

;Prom s 

ip 

jp ead prompt above field Y/N : 
gh ie field to be entered Y/N : 
jeune field to be updated Y/N : 
50> 

sis field mandatory Y/N : 

sIs field fixed length Y/N : 


sAuto jump to next field Y/N: 


tates Kee b<jee tte 


sConvert field to upper case Y/N : 


sHelp message 
Enter Member's “orp Code- This field is Mandatory! 
;Lowest value 3°: 


fee 


;Highest value ; 

;Field hame : 

HOMEP HON 

Rone of field : 

NUMBER ; ; 

cuaae of field / Display length / Query length : 
sis this field in the Lase table Y/N ; 

ie this field part of the primary key Y/N : 
*Default value : 

saa 

omen) 

40 
TCOLUDM. 2 


50 


hone eRe 

;Display prompt above field Y/N: 
Mile field to be entered Y/N : 
Hal alone field to be updated Y/N : 
tson> 

;1S field mandatory Y/N 

sIs field fixed length Y/N 

ao jump to next field Y/N 
;Convert field to upper case Y/N : 


106 


n 

;Help message : , i 

rnter Member's Home Phone in this Format- 18005551212 
sLowest value : | 


sHighest value ;: 


*Field name : 
BUSPHONE 
aes Gf field: 
NUMBER 


“ig le of field / Display length / Query length ;: 
*Is this field in the base table Y/N : 


sis this field part of the primary key Y/N: 
sDefault value : 


Peele : 
seane : 
43 
“Column : 


50 


Zeeompt ; 

Business Phone _ 

;sDisplay prompt above field Y/N ; 

Low field to be entered Y/N : 

tallow field to be updated Y/i : 

soL> 

;is field mandatory Y/N 

n 

sis field fixed length Y/N : 

n 

sAuto jump to next field Y/N : 

peony ert field to upper case Y/N : 

n 

sHelp message ; . . 

nter Member's Business Phone in this Format-18005551212x2121 
sLowest value : 

sHighest value :; 

;Field name :; 

RUIC 

ge of field ;: 

NUMBER 

pecogth of field / Display length / Query length : 
7S this field in the base table Y/N : 

“2S this field part of the primary key Y/N : 
sDefault value : 

Boo? 5 

;Line ; 

16 
poolunmn ; 


43 


werOmrt > 
eserve UIC 


107 


sDisplay prompt above field Y/N: 
eaidios field to be entered Y/N : 
Beoe field to be updated Y/N : 
SOL. 

abe field mandatory Y/N : 

-Is fieid fixed length Y/N : 


;AutO jump too nexteemerd Y/ire 


<i * Ge 


seCn Cae field to upper case Y/N : 

;sHelp message : ; ae 

Enter Member's Reserve Unit Identification Code 
sLoweSt value ; 

sHighest value : 

Field name : 

ee f eaeud 

: e of fie : 

WuAbER 

-Length of field / Display length / Query length : 
sis this field in tne base table Y/N : 

‘Is this field part cf the primary key Y/N : 
sDefault vaiue ;: 

foes : 

*Line : 
16 
TcOLuUMn. 2 
54 


[PE OR DE 


e 


iraining use . 
;Display prompt above field Y/N : 


on field to be entered Y/N : 
saree field to be updated Y/N : 
250 L> 

sIs field mandatory Y/N : 

i field fixed length Y/N : 

sAuto jump to next field Y/N ; 
RECINCES field to upper case Y/N : 


ze 


x 


sHelp message : os <2 

Enter Member's Training RUIC 1£ it 1S Diftiecrenegtaen fie 
sLowest value : 

;sHighest value : 

;Field name ; 

SSN 


ess Of tf elie: 
NOABER 
;Length of field / Display length / Query length : 


108 


S/S 40a , 

-Is this field in the base table Y/N ; 
Default value ;: 

weage ; 

yi 

Seine 

;Column 

Boa: 

>Prom : 

Soc. 6c. No. 

;Display prompt above field Y/N : 

n 

iO" field to be entered Y/N : 

woo L> 

4 hame ; 

sType of field 

NoaBER 

peength of field / Display length / Query length 
-Is this field in the base table Y/N: 

> this field part of the primary key Y/N : 
;Defauit value 

weage ; 

4 “ 

sLine : 

sColumn 3 

20 
seLompt ; 

BIEth Date 

sDisplay prompt above field Y/N : 

sAllow field to be entered Y/N : 

sAllow field to be updated Y/N : 

po L> 

Aue field mandatory Y/N : 

ae ELemderixed length Y/N : 

a. ° jump to next field Y/N 

feo overt field to upper case Y/N : 

sHelp message :_. . ; 

Entef Member's Birth Date in this Format- YYMMDD 
sLowest value : 

;Highest value 

sField name : 

us r field 

: e of fie : 

bakk . 

aoe of field / Display length / Query length 
aS this field in the base table Y/N 


109 


;is this field part of the primary key Y/N : 
sDefault value : 
*Page 3; 
ne ae 
sbane 2 
sColumn ; 
40 
-Prompt. 3 
ex 
‘Display prompt above field Y/N : 
sAllow field to be entered Y/N : 
sAllow field to be updated Y/N ;: 
pre Op 
-Is field mandatory Y/N : 
ee field fixed length Y/N : 
ee jump to next field Y/N ; 
peouvieEs fieid to upper case Y/N : 
;sHelp message ; 
M- Male F-Female 
sLowest value : 
;Highest value : 
-Field name ;: 
RACE 
eee Of fieid = 
CH > ° ° 
*Lengtk of field / Display length 7 Query Wengtae: 
-Is this field in the base table Y/N : 
sis this field part of the primary key Y/N : 
sDefault value : 
;sPage ; 
sLine : 
6 
Brown tubel: © 


60 


= eneropienc = 
ace 
pu as prompt above field Y/N : 


sAllow field to be entered Y/N : 


feeb field to be updated Y/N 
PESO in 2 

foe field mandatory Y/N : 
pte field fixed length Y/N : 


jue jump to next field Y/N : 
;Convert field to upper case Y/N 


110 


v4 

sHelp message :; ; ; ; 
mmeaicaslan, B- Black, O- Oriental, H= Hispanic 
sLowest value ; 

sHighest value : 

;Fielid name ; 

Meee of tie1a 

: e of fie : 

toaBER 

sLength of field / Display lenyth / Query length 
sis this field in the base table Y/N ; 

sis this field part of the primary key Y/N : 
;DeFault value : 

mpage : 

id 

feane >; 

feo2UMn : 

ion ct 

;Prom 3 

PEBD j 

motsplay frompt above field Y/N : 

ae field to be entered Y/N : 

oO" field to be updated Y/N : 

50 L> 

sIs field mandatory Y/N 

ih 

pas field fixed iength Y/N : 

puto jump to next field Y/N : 

Oe field to upper case Y/N : 

sHeip message : 

fnter Member's Baye onthVyebadsemvave 

sLowest value : 

;Highest value : 

-Field name : 

DEPEN 

peype of field 

zLength of field / Display length / Query length : 
sIs this field in the base table Y/N 

;is this field part of the primary key Y/N : 
;Default value 

wage > 

.. 

‘eine : 

) 

feolunn ; 


40 


*Prompt : 
Dep céde 


‘Display prompt above field Y/N :; 
sAllow field to pe entered Y/N : 
at teN field to be updated Y/N : 
-SQL> 
nue field mandatory Y/N : 
ie field fixed length Y/N : 
HENS jump to next field Y/N : 
sConvert field to upper case Y/N ;: 
sHelp message : 
Enter Member's Dependency Code 
sLowest value : 
sHighest value : 
;Fleld name : 
CLRACCESS _ << 
: eo ie : 
énkk 
sLength of field / Display length / Query length 
je this field in the base table Y/N : 
sis this field part of the primary key Y/N : 
*-Default value : 
;Page 3: 
5 oo 
‘Lane. $ 
-Coneu Nn) a: 
58 
sPrompt : 
earance 
;Display prompt above field Y/N : 
oe field to be entered Y/N : 
a field to be updated Y/N : 
oO 
sits field mandatory Y/N : 
sis field fixed length Y/N ; 


sAuto jump to next field Y/N 


—<po 


p<ive o p-<te 


sConvert field to upper case Y/N 


<he 


sHelp message ;: 
UNCLAS,CONFID,SECRET , TOPS EC 
“Lowest value : 

sHighest value 

*-Field name 

PAYGRADS a. 

: eo ie : 

épik 


;sLength of field / Display length / Query length 


112 


1 
eS this field in the base table Y/N : 
sIs this fieid part of the primary key Y/N ;: 


;Default value : 


;Display prompt above field Y/N: 
jALlow field to be entered Y/N ; 
a field to be ufdated Y/N : 
.30L> 

mes field mandatory Y/N : 

sis field fixed length Y/N : 

Auto jump to next field Y/N: 

peo crt field to upper case Y/N 
gHelp message ; 
Enter Member's Pay Grade from Appendix 
sLowest value : 

;Highest value : 


“Field name 


DOR 


feaes of field 

NUMBER ; : 

pecug th of field / Display length / Query length : 
iS this field in the base table Y/N : 

ae this field part of the primary key Y/N : 
sDefault value 

-Page : 

ihe 

sLine 3; 

feOLunNn : 

40 

weEOompt : 


1 


Date of Rank 
;Display prompt above field Y/N ;: 


eo field to be entered Y/N : 
oe Prema to be updated Y/N :; 
310 b> 

sis field mandatory Y/N : 


ine field fixed length Y/N ; 


saute jump to next field 17 ew 
sConvert field to upper casey : 


N 


sHelp message : 

Enter Member's Date of Rank or Rate- YYMMDD 
sLowest value ;: 

;Highest value : 

‘Field name : 

- f field 

: eo ie : 

MoaBER 

sLength of field / Display length / Query length ; 
-Is this field in the base table Y/N 

ie this field part of the primary key Y/N : 
‘Default value ; 

‘Page ; 

2 

Soane Ss 

12 
“CoO man. < 

58 

a OME : 

sDisplay prompt above field Y/N ; 
foun field to be entered Y/N : 
sAllow field to be updated Y/N ; 
250 b> 

iS ftiela pandatony Ne. 

Is field fixed length Y/N : 
sAuto jump to next field Y/N 


;sConvert field to upper case Y/N : 


ree 


<teo r<jee 


a 


sHelp message : ; : 

Eater Member's Expiration Of Service 

s;Lowest value : 

sHighest value ; 

sField name ;: 

eae i Ele 

: eo ie : 

oa BER 2 

gees of tield / Display length / Query length ; 
-Is this field in the base table Y/N : 

ee this field part of the primary key Y/N : 
>Default value : 

sPage ¢$ 

ae 

‘Laine 3; 

5 


“COLumn- 


20 

7 Lomnpt ; 

recedence No. 

sDisplav prompt above field Y/N : 

Allow field to be entered Y/N : 

aa field to be ufdated Y/N : 

2o0L> 

sls fieid mandatory Y/N : 

Is field fixed length Y/N : 

eect jump to next field Y/N :; 

;sConvert field to upper case Y/N : 

sHelp message : 

Enter Member's Precedence Number 

sLowest value ; 

sHighest value : 

*Field name :; 

Ty r field 

: e or fie : 

fGnBER ag 

sbength or field / Display length / Query length : 
*Is this field in the base table Y/N: 

> this field part of the primary key Y/N ; 
sDefault value : 

;Page : 

a 

jeene 

15 

peo lumn s 

40 
feeOonpt : 

Hop | 
sDisplay prompt above field Y/N : 
sAllow field to be entered Y/N :; 
sAllow field to be updated Y/N : 
750 > 

-Is field mandatory Y/N : 

jis field fixed length Y/N : 
;Auto jump to next field Y/N : 
fa ert field to upper case Y/N : 
sHelp message ;: 

mie Heaber's MOD 

sLowest value : 

;Highest value : 


‘Field name : 
EYRAA 


pat of -~El1eld = 

NUMBER 

sLength of field / Display length / Query length :; 
-Is this field in the base table Y/N : 


ohKee Ove 


-Is this field part of the primary cre, 17 
;Default value : 

srage =: 

i 

;Lene- : 


45 


“Column 2 
58 


rg 
me | 
'e) 
5 
ce) 
c+ 
be 


sDisplay prompt above field Y/N : 
sAllow field to be entered Y/N ;: 
ee field to be updated Y/N : 
<oOlL> 
tS field mandatory Y/N : 
sis field fixed length Y/N : 
Poe jump to next field Y/N : 
A tak: field to upper case Y/N : 
sHelp message 
inter Member's EXRAA- YYMMDD 
sLowest value ; 
;sHighest value : 
ee hame : 
Lins £ field 
Z a5 ie : 
fIyRe . 
Length of field / Display length / Query length ; 
ie this field in the base table Y/N : 
325 this field part of the primary key Y/N ; 
sDefault vaiue : 
;Page 3 
ae 
ee 0 
18 
zColumn - 
20 


+P SO Map tenes 
Linea No. 
;Display prompt above field Y/N : 


<< 


Allow field to be entered Y/N 


<j? 


Allow field to be updated Y/N : 
oC 


bie 0 


;is field mandatory Y/N : 


N 
eS preld fixed Vengtk yn : 
Pato jump to next field Y/N : 
Pee ert field to upper case Y/N 
sHelp message : 
Enter Member's Lineal Number 
s;Lowest value : 
sHighest value : 
eld nam 
BHOEC OR PNEC 
yee wOLe feild = 
ae gta of field / Display iength / Query length : 
sis this field in the base table Y/N: 
as this field part cof the primary key Y/N : 
Default value : 
sPage : 
2 
PLL ne 
18 
meolunn : 


58 


ee be 

NOBC/ NEC 

ee tay prompt above field Y/N: 
Of Tield to be entered Y/N :; 
ca" field to be updated Y/N 
0 L > 

— field mandatory Y/N : 

prs tield fixed length Y/N : 


fl 
tO jump to next field Y/N 


Convert field to upper case Y/N : 


© [thes iiwe 


sHelp message : 

DP Gtee seine sate NOBC or NEC 

sHighest vaiue : 

bez? name : 

ne e of field : 

jlength of field / Display length / Query length 
a this field in the base table Y/N : 

aa this field part of the primary key Y/N : 
;Derault value : 


*Page : 
5 G 


ep : 
eocuee 

peo : 

‘Display prompt above field Y/N ; 
sAllow field to be entered Y/N : 
sAllow field to be updated Y/N : 
;00L> 

sis field mandatory YN : 
sis=fileld £ixed length y7h 7 
sAuto jump to next field Y/N : 


;Convert field to upper case Y/N : 


ones 


=m 


3Help message 

Enter Member's “Coct e 
Mest value : 

;sHighest value : 

es hame : 

SuBC 
izype of field ;: 

Length of field / Display length / Query length 
ee this field in the base table Y/N : 

ee this field part of the primary key Y/N : 
sDefault value : 

sPage ; 

— 

‘Lael: 

21 
ae ominelila 


58 


7PrOMP ts 

Subspecialty 

;sDisplay prompt above field Y/N: 
field to be entered Y/N : 
+ Adiiow field to be updated Y/N : 
tson> 

;ls field mandatory Y/N 

;is field fixed length Y/N : 


;Auto jump to next field Y/N : 


poe 


=| 


Y ae 

sConvert field to upper case Y/N 
n 

;Heip message 5 

Enter member's Subspecialty Code 
sLowest value ; 


;sHighest value : 


*Field name : 
sorock name / Descriftion ; 


Se eee ORMAT ION 
*END 


Piaex 
Name 


NAME RUIC 
NAME ZIP 
NAME_SSN 
SSN_LANG 
LANG_SSN 


SSN EDUCATION 
NAME _TRUIC 


CLR_SSN 
DRILL_SSN 
DRILL_NUM 


APPENDIX D 
PROTOTYPE INDICES 


Index 
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